Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 中国では、2023年8月1日に強制力のある国家標準規格「GB 18030-2022」(信息技術中文編碼字符集)が施行される。中国で「強制」という言葉が出ると「また締め付けが強化される」と反射的に考えてしまうかもしれないが、これは文字コードの標準規格を新たに導入するという話だ。珍しい名字などに使われ、既存の文字コードに未登録の漢字に対応しようというものになる。 中国の面積は日本の国土の約25倍で、約14億人の人口を擁している。一部の地域限定で使われている漢字や、少数民族の固有名詞でのみ用いられている漢字もある。文字コードに含まれない漢字を使っている人は約6000万人もいるそうだ。例えば、山東省青島市郊外にシュイユー村という地元ではまあまあ
Java のリリースサイクル が変更され、2019/01 現在の Java の最新バージョンは早 11。文法面での改善も進んでおり、モダンな Java のスタイルにも変化が見られる。この記事では Java 11 時代におけるモダンな Java プログラミングのスタイルをまとめてみたい。 筆者の主観を多分に含むため、その点ご注意を。 var(ローカル変数の型推論) var を積極的に利用する。 Java 10 で導入された var によるローカル変数の型宣言だが、基本的には使用できる場面では積極的に使用するというスタンスでよいだろう。モダンな言語の多くは同様の型推論を採用しているが、それで問題になったという話は聞かない。 高度に訓練された Java プログラマーにとっては左辺の型定義など IDE が自動補完してくれるので便利さを感じないという意見には一理あるのだが、コードを読むときに限っては
当社はCookieを使用して、お客様が当社のWebサイトでより良い体験を得られるようにしています。引き続き閲覧する場合は、プライバシーポリシーに同意したことになります。
みなさんは、JavaScriptのコードを書くときに文字列は何で囲みますか?シングルクォート?ダブルクォート? インデントに使用する文字はスペース?それともタブ? JavaScript Standard Styleは、そのように千差万別なコーディングスタイルを統一するためのスタイルガイドの一つです。1 JavaScript Standard Styleのルール JavaScript Standard Styleには、次のようなルールがあります。 インデントはスペース2個 文字列はシングルクォートで囲む 未使用の変数は禁止 文末のセミコロンは禁止 キーワードの後にスペースを入れる 関数名の後にスペースを入れる 値の比較に==ではなく===を使用 ただしobj == nullはnull || undefinedをチェックするために許容される 常にNode.jsのerr引数をハンドル ファイルの
これはRuby Advent Calendar 2018の4日目の記事になります。昨日はpink_bangbiさんのあなたのしらない Refinements の世界でした。 一行まとめ Rubyのコミュニティ共有コーディングスタイルを目論むStandard gemをJustin Searlsが作っているので、意見があれば議論に参加しましょう! Rubyのコーディングスタイルについて Rubyには公式のコーディングスタイルが決められていません。また公式のフォーマッターもありません。Ruby作者のまつもとさんは、コーディングスタイルについて、積極的には統一ルールを打ち出そうとはしていないようです。 まつもとさんの考えていることと、コーディング規約&オートフォーマッタの現状についてはSiderのインタビューに詳しいです。ちょっと長いですが引用します。 まつもと : コーディング規約を決めてくれな
当社はCookieを使用して、お客様が当社のWebサイトでより良い体験を得られるようにしています。引き続き閲覧する場合は、プライバシーポリシーに同意したことになります。
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに クラウドワークスの初期バージョンを作ってから早6年。後任のエンジニアたちには様々なdisりを受けてきました。 システムアーキテクチャや設計(命名は除く)に関するdisりについては、何よりもビジネスを軌道に乗せることが優先されるタイミングでどこまで「ちゃんと」やるべきか、という議論の余地が常にあります(自分のスキル不足については、いったん棚に上げます)。 一方、「命名」については、サービス立ち上げ期であっても「ちゃんと」やるべきと断言できます。 なぜならば、 システム外(例えば、非エンジニアとのコミュニケーション)にも関係してく
(Last Updated On: 2018年9月13日)ISO 27000(ISMS)をはじめ、セキュアコーディング/セキュアプログラミングを行いなさい、と推奨するセキュリティガイドラインが多くあります。2014年改訂のISO 27000に至っては、セキュアプログラミングが広く普及したのでセキュアプログラミングを行うとする記述に簡素化しています。1 しかし、広く使われているフレームワークでさえセキュアコーディング/セキュアプログラミングをサポートする機能が無かったり/不十分でだったり、現状は到底普及している、とは言えないです。辛うじて普及しているかも?と言えるのはセキュアコーディング/セキュアプログラミングでは枝葉末節にあたるコーディング技術(ああすべき/こうすべき)くらいではないでしょうか? なぜセキュアコーディング/セキュアプログラミングが普及していないのか?考えられる理由を挙げます
アメリカ人です。 Hello 👋 この記事の目的 多くの日本人は自分の英語力には自信がないではないでしょうか。残念ながら「英語がわからん」、「英語が全然できない」という声をしょっちゅう聞いています。でも、今まで英語ができて意味がちゃんと伝わる何人かの日本人に会ったがあります。完璧な英語ではないけど(外国人も英語でミスる時もある...)、がんばって話そうとするので充分仕事ができる人たち。そういうがんばる姿勢はオープンソースのプログラムや英語圏のプログラムに手を出すためには一番大事なことだと思います(外国人側もすごく助かります)。日本の文化では「私はできる!」と自慢することは少ない中、この記事を通して、流暢に話せなくても自分のプログラミングの命名の仕方にはちょっとだけでも自信を持たせたいなと思います。完璧じゃなくていいです。Let's go! 合わせて読んでいただきたい 【日本人エンジニア必
色々なところで見かけるコーディング規約を見て意識はしているのですが、 その時の気分で書き方を変えてしまうことが多々あったので、自戒を込めてコーディング規約をまとめてみました。 「なぜこの規約が存在するか」を明確にするために、できる限り理由も併記しています。 ただかなり主観的な部分があるので、あまり意味がないかもしれません…。 「この記事のこの規約は気に入らない。」と思うことがきっとあると思います。 その時はコメント欄などに理由も合わせて書いてくれると嬉しいです。 この記事ではRubyのコーディング規約をまとめています。 近いうちにRailsとCoffeeScriptのコーディング規約もまとめるつもりです。 Rubyのコーディング規約は以下のページを参考にまとめました。 https://github.com/styleguide/ruby https://github.com/bbatsov
先週、 Hacker News上で興味深い議論が行われました 。テーマは Linux Kernelのコーディングスタイル についてです。 議論の中で私は、 コーディングで垂直方向にそろえるインデントをとるべきか というささやかな聖戦を仕掛けました。私は全面的に賛成です。理由を説明しましょう。 垂直方向にそろえるインデントをとるとは? 簡単な例を挙げてみます。 int robert_age = 32; int annalouise_age = 25; int bob_age = 250; int dorothy_age = 56; ちょっと見ただけで、「bob_age」がおかしいと分かるでしょう。また、目視であちこち探さなくても、全ての値が整数であることが簡単に確認できます。 この考え方は 一般的に 共有 されているわけではありません。ですので、なぜ 多くの 人たち がこれを有効なスタイルガ
人間長い間生きていると、一度くらい夜中にヒンディー語の入ったファイルを修正する必要がでてきます。 手持ち(Windows)のサクラエディタや、vimでは残念ながらインドの偉大な英知を表示してくれはしませんでした。 ここでは、夜中にヒンディー語を修正するはめになり、かつ、グーグル先生に聞いてクールな多言語対応のエディタを探してインストールする余裕もないときに、どう対応すべきかを記述します。 ここでは、ブラウザー経由でヒンディー語の入ったファイルを修正してファイルに保存するようにします。 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xm
■ [prog] コメントの話 去年くらいから仕事のコードでは、privateも含めて全部のメソッドに「何をするメソッドか」という簡単な説明を書くように心がけています。 こういうやつですね。 # このレコードの種類を文字列で返す # 種類が未定義の場合はnilを返す def type_name FOO_NAMES[self.foo_type] end 理由をメモ的にまとめておきます。 1. コメントがあると読む人が助かる バグ修正や機能追加とかで、コードを読む機会というのはけっこうある。そういうときにメソッド単位でコメントがあるとすごく助かる。*1 1行書いておくだけで情報共有のコストが下がるなら、充分良い投資ではないかと思います。 あるいはメソッドを短くして適切なメソッド名を付ければ、コメントは要らないのではと考えたこともあるけど、本当に意図がソースから自明になることって少ないんですよね
Lv1, Lv2 ともに ciel様 の圧勝でした!! また、2位の tomwot様 も他の解答者と比べるとかなり飛び抜けていました。 5.「Ruby警官から警告を受けろ Lv1/Lv2」問題の出題者解答例 Lv1 解答例(警告24種) class Answer def aA( a) c=12345 ["a","b"] [].map{|v|v} "h"#TODO: ; {:a=>1} %w{} a(1, 2) end end 発生する警告 1, %w-literals should be delimited by ( and ) 2, Align the parameters of a method call if they span more than one line. 3, Annotation keywords should be all upper case, followed
コーディング規約を作ろうコーディング規約やスタイルガイドは、HTMLやCSSのマークアップや、各種プログラミング言語の書き方をまとめたものです。コーディングスタンダードやコーディングガイドラインとも呼ばれますね。コーディング規約を決めていなかったり、あいまいにしたまま進めていくと、書式が統一されていないため、コードを追加すればするほどゴチャゴチャしたコードになりがちです。チームでコーディングしていくならなおさら。今回チーム用のコーディング規約を見直すことになったので、その時感じた抑えておくべきポイントをまとめてみます。 コーディング規約に含むべき項目ディレクトリー階層ファイルを保存するフォルダーの階層や、そのフォルダーの名前を決めておきます。画像を格納しているフォルダーを例にあげても、「image」「images」「img」などの名前が考えられます。人によってつけるフォルダーの名前が変わっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く