アカウント名:
パスワード:
ファイルと関数/変数名、ついでにテーブル関連を全て全半角混じり文字(および10語ぐらいの文章)にしたら、怒られた。OSや言語、DBMS的に動作保証されてるし、日本人的に分かりやすく、可読性という意味でメンテしやすいのだから良いだろ別に… と思った
メンテしにくいだろ。見た目の区別がつきにくい文字があるだろうが。
「1とI(アイ)とl(エル)、0とOは似てるので利用禁止」なプロジェクトって存在するのか？-と_および-と~や、.と,も似ているし、'と"と`も含めて使うなと言われると開発言語自体の選定が困難。
そういや昔話だがOracleにSJISでスキーマ定義した奴がいて、後にOracleをアップデートしようとしたらシステムがUTF-8だとバイト数の制限で移行できないというバカがいたな。（1文字2BYTEが3BYTEになってテーブル名だか列名だかの制限超えたらしいw）そもそも当時のOracleは非ASCIIなテーブル名とか保証してないのにいきってやってたらしい。（裏技的に定義できたけど保証はしてない）そのシステムのためだけにOracleがSJISのままにとなって大変だったらしいw
別にバカじゃないよ。SQLというかRDBMは昔から多言語対応が多くてSQL教本でも普通に日本語カラム名使ってたくらいは普通に使えたんだけどな。Oracleがバカなだけ
自分しか使わないものはそれでもいいが、共同開発する場合は一貫性をもった命名にしないと、可読性が著しく低下する。既存のライブラリとの一貫性も考慮するなら、通常の命名は英語一択。怒られるのは当然。
法律関連/税務関連のプログラムは、変数名や関数名でその手の用語は必ず漢字なりの日本語使うのが基本。ローマ字とかにすると一文字違いで全く別のものを扱ってしまうこともあるし、英訳も一意に決まると限らん。その手のミス一つですら数億単位の損害賠償になったりするから、そちらの分野では日本語で命名するってのが一貫性をもったスタイルで、要求仕様だったりするんだよね。
× 法律関連/税務関連のプログラムは、○ ボクが一回だけどこかの噂話で聞いたことがある法律関連/税務関連のプログラムは、
無駄に主語をデカくしないように。
一般的な開発言語のキーワードが多言語対応したものが中心になってから、もう四半世紀なんですよ。旧時代の資産が活きてるところも多いですが、いまどきは普通に活用するのが一般的ですし、いまでは適用分野によっては不具合が確実に減ることが数値で出るぐらいには、いろんなところで実践された時代なんですよ。(なので、最近は要求にものってくる)
> 旧時代の資産が活きてるところも多いですが、いまどきは普通に活用するのが一般的ですし、どっちやねん。設定がブレブレやぞ。
でも、使っている外部ライブラリの関数名が、ある日から中国語名に変わっていたりしたらキレるでしょ？
これに関してアホは君や。会計なんて毎年改定される税法対応がメインで食ってるようなもんなんだからよほどの大企業でもなければ輸出とか考えるわけないでしょ。国内でカッチリ動くのが重要なんだから日本語使うのは全くの自然。
そもそもSQLって現場(プログラマじゃなくて経理担当等)が使えるようにって作られたんだからドメスティックな実装自体がアリなんだよ。
開発環境の関係(複数のエディタ使用)でTabとスペースが混在したコード書いてたら怒られたことあったっけそんなに気になるならわざわざ空白文字表示設定なんか有効にしなきゃいいのにとは思った
それは怒られるだろ常識的に考えて。エディタのせいにするな。他のメンバーからしたらお前のエディタの事情なんか知らん。お前がコミットしたコードはお前の成果物であってエディタの成果物ではない。責任はエディタ0%お前100%だ。
そう言う奴が居るから、開発にはこのエディタを使うことみたいな開発ルールを作らざるを得なくなるんだよ。
もし今でもそう思っているのならプログラムを書く仕事はやめた方がよい。
経歴書のその意見書いといてくれると助かる
この画像 [emacswiki.org])思い出したｗまあソフトウェアってのは究極的にはビルドした実行ファイルがちゃんと動けばそれでいいと思ってるからあんまり気にしたことはないな
＞ 究極的にはビルドした実行ファイルがちゃんと動けばそれでいい
むかーしむかーしだけど、この考えの外注の人が、ソースが出来てたら文句ないだろｗって設計書書きをサボって、今日中間納品で客先に設計書出すぞって言われて何もできて無くて逃げた事件があったわ。（あれ？あの人は？どこ行った？とか話してたら、突然のお世話になりましたメール。）
個人でソフト作るだけならともかく、納品物はそうじゃないことが多いので注意しましょうって話でした／(^o^)＼
最初の吹き出しがクロスしてるのは何か意味あるんだろうか
空白レベルですら一貫性が保てない人が一貫性のあるコードを書けるわけがない。
否定的なコメントが多いけど、コーディング規約でインデント文字が規定されてないなら怒られる理由はない。
怒られるわ。チームで開発するソフトウェアは、1つのファイルでも複数の人間によってメンテナンスされる。そこで、各人が各々TAB幅の設定が違うエディタで、TABやスペース混在で編集していくと、インデントがぐちゃぐちゃになって収拾つかなくなっていくんだよ。
まあそういう表記のゆれを修正するコード整形ツールは多々あるので、自分が好きな作法で編集した後にそういうツールを一旦通してからコミットするというなら問題は無い。
そこまで言うなら規約設定しろよw
俺今までインデント文字で文句言われたことないな(全部SP派
陰で「チッ。またあいつかよ。クソが」と思われてるかもよw
それを怒られない事を不幸と思え。
ぼくのかんがえるさいきょうのこーでぃんぐすたいるじゃなきゃいやだいやだと駄々こねてるようにしか見えんインデントにスペースとタブが混じってる程度のコードは怒るほど汚いうちに入らん
インデントにスペースとタブが混じってる程度のことすら直せん奴が々こねてるようにしか見えん
っ鏡混じってるのが許せないと怒る本人が直せばいいことでしょ他人に怒るとこが駄々こねてると言われるのよ
タブスペース不統一の分かりやすい弊害としては、プログラム的に無意味な空白部分で差分が発生しやすくなるというもの。コミット前に整形ツールを通させるのは、そういった記述ブレを取り除く意味が大きい。
一般的な開発現場はEditorConfigでコントロールする。そもそもタブスペースが混在する状況自体発生せず、規約を確認する必要もない。
そのような諸々の仕組みをブロックしてタブスペースが混在するコードを成果物としていれば「怒られる」のが普通だが、それが怒られないとすれば、その新人を教育する環境も、開発するための環境もまともに整備されていないことを意味する。
これを不幸と言わずなんと言おうか。
コーディング規約で縛れ。できてなかったなら不幸を呪って諦めろ。他人に当たるな。以上。
コーディング規約でスペース/タブが定義されてない現場なんてないだろ。諦めて統一しろ。
最初に、コーディング規約でインデント文字が規定されてないなら、と断ってるんだが？>コーディング規約でスペース/タブが定義されてない現場なんてないだろなんて俺様常識で言っちゃうところが、おこちゃまがダダこねてるとしか見えないんだとどうしてわからんのかな
まあEditorConfigという文化について調べることから始めてみてはどうかな。君の知っているプロジェクトで.editorconfigというファイルを見かけたことはないかね。
eclipseでコーディングしてた時のこと。
まず設定の [一般]-[エディター]-[テキスト・エディター] の中に「タブでスペースを挿入」という設定がありそいつを調整してコーディングを始めたんだが、どうも設定どおりにいかない。
散々探し回った挙句、[Java]-[コード・スタイル]-[フォーマッター] のプロファイルの中にもタブ・スペースの設定がある事をようやく突き止めた。てめぇ・・・eclipseそういうとこやぞ・・・と思った。
# これにAnyEditプラグインやeditorconfigを絡めて炒めると、さらに美味しく。
蛇使いのワイ高みの見物# 先の時代の言語つかいたちはたいへんだなーとづまりすとこ
落語の寿限無みたいなソースコード、当人以外誰も読みたくない
× OSや言語、DBMS的に動作保証されてるし、○ たまたまその時使っていたバージョンのOSや言語、DBMS的にだけは動作保証されてるし、将来の環境変化や接続相手のシステムやデータの二次利用は一切考慮してないけど、
世界的にUTF-8への流れだしASCIIにしがみつく必要はないと思うよ、おじいちゃん
> 世界的にUTF-8への流れだしこんな理由で無駄にリスクを増やす選択をする君はエンジニアに向いてない。
エンジニアじゃないでしょうね．外注先がこうなら，次から発注先変えます．
# 若くても年寄りでも関係ないです．年齢の問題ではなく工学がわかっているかどうかのレベルで．
リスクなぁ……具体的にどんなリスクが有るの？そのリスクは処理系のバージョンアップでライブラリが使えなくなったりするリスクとくらべて大きいの？しょもないことを気にするなあ
比べる対象が間違ってる。
ASCIIだけ使ってればリスクゼロ。UTF-8を使うとリスクゼロじゃなくなる。
これを、> しょもないことを気にするなあと考える君はエンジニアに向いてない。他のまともなエンジニアに迷惑をかける前に、リスク評価もロジカルな思考も不要な職業に転職することをおすすめする。
具体的なリスクになってない、やり直し。リスクがあるからリスクがあるんだってそれただのトートロジーだから。
みんな「論理名」と「物理名」を区別する事に慣れちゃってると思うんよな。予期しない場所で日本語を見かけると「論理名がなぜここに！？」と驚いちゃうし、不安になるかもね。あと正規表現 /[\w_]+/ とか /\b/ とかで対応できないのも、しばしばgrepに命を救われてきた歴戦の技術者にとってはストレスの材料になると思う。
コメントとコードが一目でわかる、というのは非ラテン文字圏のメリットだと思うんよね母語で変数名関数名を書いたらニュアンスの細かいところとかが気になったりもするし
なので俺も分けとく方がいいと思う
君の正規表現の認識が古い
へんなレスがついてる(;´Д`)なにこれ
複数形とかキャメルケースで悩むならまだありかもだが全角なんてとんでもない！
データベースオブジェクトの命名規約https://qiita.com/genzouw/items/35022fa96c120e67c637 [qiita.com]
その動作保証されてて、日本人的に分かりやすくて、可読性という意味でメンテしやすいはずの方法を誰も使ってない理由を考えなかったのかな。もしかして、こんな素晴らしい方法を考えたボクちゃんが天才で、今までこれに気づかなかった奴らは全員無能、とか思っちゃったのかな？
たまーにおるよな、こういう自分の書いた狭い範囲のことしか見えてなくてシステム全体とか外接先への影響とかへの思慮が足りてないやつ。だいたいすぐ帰任になって受け入れの手間だけ取らされるからマジで迷惑。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
罵倒されたことはある (スコア:0)
ファイルと関数/変数名、ついでにテーブル関連を全て全半角混じり文字(および10語ぐらいの文章)にしたら、怒られた。
OSや言語、DBMS的に動作保証されてるし、日本人的に分かりやすく、可読性という意味でメンテしやすいのだから良いだろ別に… と思った
Re:罵倒されたことはある (スコア:1)
メンテしにくいだろ。見た目の区別がつきにくい文字があるだろうが。
Re: (スコア:0)
「1とI(アイ)とl(エル)、0とOは似てるので利用禁止」なプロジェクトって存在するのか？
-と_および-と~や、.と,も似ているし、'と"と`も含めて使うなと言われると開発言語自体の選定が困難。
Re:罵倒されたことはある (スコア:1)
そういや昔話だがOracleにSJISでスキーマ定義した奴がいて、後にOracleをアップデートしようとしたらシステムがUTF-8だとバイト数の制限で移行できないというバカがいたな。（1文字2BYTEが3BYTEになってテーブル名だか列名だかの制限超えたらしいw）
そもそも当時のOracleは非ASCIIなテーブル名とか保証してないのにいきってやってたらしい。（裏技的に定義できたけど保証はしてない）
そのシステムのためだけにOracleがSJISのままにとなって大変だったらしいw
Re: (スコア:0)
別にバカじゃないよ。
SQLというかRDBMは昔から多言語対応が多くて
SQL教本でも普通に日本語カラム名使ってたくらいは普通に使えたんだけどな。
Oracleがバカなだけ
Re: (スコア:0)
自分しか使わないものはそれでもいいが、共同開発する場合は一貫性をもった命名にしないと、可読性が著しく低下する。
既存のライブラリとの一貫性も考慮するなら、通常の命名は英語一択。
怒られるのは当然。
Re:罵倒されたことはある (スコア:1)
法律関連/税務関連のプログラムは、変数名や関数名でその手の用語は必ず漢字なりの日本語使うのが基本。ローマ字とかにすると一文字違いで全く別のものを扱ってしまうこともあるし、英訳も一意に決まると限らん。
その手のミス一つですら数億単位の損害賠償になったりするから、そちらの分野では日本語で命名するってのが一貫性をもったスタイルで、要求仕様だったりするんだよね。
Re: (スコア:0)
× 法律関連/税務関連のプログラムは、
○ ボクが一回だけどこかの噂話で聞いたことがある法律関連/税務関連のプログラムは、
無駄に主語をデカくしないように。
Re: (スコア:0)
一般的な開発言語のキーワードが多言語対応したものが中心になってから、もう四半世紀なんですよ。
旧時代の資産が活きてるところも多いですが、いまどきは普通に活用するのが一般的ですし、いまでは適用分野によっては不具合が確実に減ることが数値で出るぐらいには、いろんなところで実践された時代なんですよ。(なので、最近は要求にものってくる)
Re: (スコア:0)
> 旧時代の資産が活きてるところも多いですが、いまどきは普通に活用するのが一般的ですし、
どっちやねん。
設定がブレブレやぞ。
Re: (スコア:0)
でも、使っている外部ライブラリの関数名が、ある日から中国語名に変わっていたりしたらキレるでしょ？
Re: (スコア:0)
これに関してアホは君や。
会計なんて毎年改定される税法対応がメインで食ってるようなもんなんだから
よほどの大企業でもなければ輸出とか考えるわけないでしょ。
国内でカッチリ動くのが重要なんだから日本語使うのは全くの自然。
そもそもSQLって現場(プログラマじゃなくて経理担当等)が使えるようにって作られたんだから
ドメスティックな実装自体がアリなんだよ。
Re: (スコア:0)
開発環境の関係(複数のエディタ使用)でTabとスペースが混在したコード書いてたら怒られたことあったっけ
そんなに気になるならわざわざ空白文字表示設定なんか有効にしなきゃいいのにとは思った
×エディタの都合 ○お前の都合 (スコア:0)
それは怒られるだろ常識的に考えて。
エディタのせいにするな。他のメンバーからしたらお前のエディタの事情なんか知らん。
お前がコミットしたコードはお前の成果物であってエディタの成果物ではない。
責任はエディタ0%お前100%だ。
そう言う奴が居るから、開発にはこのエディタを使うことみたいな開発ルールを作らざるを得なくなるんだよ。
Re: (スコア:0)
もし今でもそう思っているのならプログラムを書く仕事はやめた方がよい。
Re: (スコア:0)
経歴書のその意見書いといてくれると助かる
Re: (スコア:0)
この画像 [emacswiki.org])思い出したｗ
まあソフトウェアってのは究極的にはビルドした実行ファイルがちゃんと動けばそれでいいと思ってるからあんまり気にしたことはないな
Re: (スコア:0)
＞ 究極的にはビルドした実行ファイルがちゃんと動けばそれでいい
むかーしむかーしだけど、この考えの外注の人が、ソースが出来てたら文句ないだろｗって設計書書きをサボって、今日中間納品で客先に設計書出すぞって言われて何もできて無くて逃げた事件があったわ。
（あれ？あの人は？どこ行った？とか話してたら、突然のお世話になりましたメール。）
個人でソフト作るだけならともかく、納品物はそうじゃないことが多いので注意しましょうって話でした／(^o^)＼
Re: (スコア:0)
最初の吹き出しがクロスしてるのは何か意味あるんだろうか
Re: (スコア:0)
空白レベルですら一貫性が保てない人が一貫性のあるコードを書けるわけがない。
Re: (スコア:0)
否定的なコメントが多いけど、コーディング規約でインデント文字が規定されてないなら怒られる理由はない。
Re: (スコア:0)
怒られるわ。
チームで開発するソフトウェアは、1つのファイルでも複数の人間によってメンテナンスされる。
そこで、各人が各々TAB幅の設定が違うエディタで、TABやスペース混在で編集していくと、
インデントがぐちゃぐちゃになって収拾つかなくなっていくんだよ。
まあそういう表記のゆれを修正するコード整形ツールは多々あるので、
自分が好きな作法で編集した後にそういうツールを一旦通してからコミットするというなら問題は無い。
Re: (スコア:0)
そこまで言うなら規約設定しろよw
俺今までインデント文字で文句言われたことないな(全部SP派
Re: (スコア:0)
陰で「チッ。またあいつかよ。クソが」と思われてるかもよw
Re: (スコア:0)
それを怒られない事を不幸と思え。
Re: (スコア:0)
ぼくのかんがえるさいきょうのこーでぃんぐすたいるじゃなきゃいやだいやだ
と駄々こねてるようにしか見えん
インデントにスペースとタブが混じってる程度のコードは怒るほど汚いうちに入らん
Re: (スコア:0)
インデントにスペースとタブが混じってる程度のことすら直せん奴が々こねてるようにしか見えん
Re: (スコア:0)
っ鏡
混じってるのが許せないと怒る本人が直せばいいことでしょ
他人に怒るとこが駄々こねてると言われるのよ
Re: (スコア:0)
タブスペース不統一の分かりやすい弊害としては、プログラム的に無意味な空白部分で差分が発生しやすくなるというもの。
コミット前に整形ツールを通させるのは、そういった記述ブレを取り除く意味が大きい。
一般的な開発現場はEditorConfigでコントロールする。
そもそもタブスペースが混在する状況自体発生せず、規約を確認する必要もない。
そのような諸々の仕組みをブロックしてタブスペースが混在するコードを成果物としていれば「怒られる」のが普通だが、
それが怒られないとすれば、その新人を教育する環境も、開発するための環境もまともに整備されていないことを意味する。
これを不幸と言わずなんと言おうか。
Re: (スコア:0)
コーディング規約で縛れ。できてなかったなら不幸を呪って諦めろ。他人に当たるな。
以上。
Re: (スコア:0)
コーディング規約でスペース/タブが定義されてない現場なんてないだろ。諦めて統一しろ。
Re: (スコア:0)
最初に、コーディング規約でインデント文字が規定されてないなら、と断ってるんだが？
>コーディング規約でスペース/タブが定義されてない現場なんてないだろ
なんて俺様常識で言っちゃうところが、おこちゃまがダダこねてるとしか見えないんだとどうしてわからんのかな
Re: (スコア:0)
まあEditorConfigという文化について調べることから始めてみてはどうかな。
君の知っているプロジェクトで.editorconfigというファイルを見かけたことはないかね。
Re: (スコア:0)
eclipseでコーディングしてた時のこと。
まず設定の [一般]-[エディター]-[テキスト・エディター] の中に「タブでスペースを挿入」という設定があり
そいつを調整してコーディングを始めたんだが、どうも設定どおりにいかない。
散々探し回った挙句、[Java]-[コード・スタイル]-[フォーマッター] のプロファイルの中にもタブ・スペースの
設定がある事をようやく突き止めた。
てめぇ・・・eclipseそういうとこやぞ・・・と思った。
# これにAnyEditプラグインやeditorconfigを絡めて炒めると、さらに美味しく。
Re: (スコア:0)
蛇使いのワイ高みの見物
# 先の時代の言語つかいたちはたいへんだなーとづまりすとこ
Re: (スコア:0)
落語の寿限無みたいなソースコード、当人以外誰も読みたくない
Re: (スコア:0)
× OSや言語、DBMS的に動作保証されてるし、
○ たまたまその時使っていたバージョンのOSや言語、DBMS的にだけは動作保証されてるし、将来の環境変化や接続相手のシステムやデータの二次利用は一切考慮してないけど、
Re: (スコア:0)
世界的にUTF-8への流れだしASCIIにしがみつく必要はないと思うよ、おじいちゃん
Re: (スコア:0)
> 世界的にUTF-8への流れだし
こんな理由で無駄にリスクを増やす選択をする君はエンジニアに向いてない。
Re: (スコア:0)
エンジニアじゃないでしょうね．外注先がこうなら，次から発注先変えます．
# 若くても年寄りでも関係ないです．年齢の問題ではなく工学がわかっているかどうかのレベルで．
Re: (スコア:0)
リスクなぁ……
具体的にどんなリスクが有るの？
そのリスクは処理系のバージョンアップでライブラリが使えなくなったりするリスクとくらべて大きいの？
しょもないことを気にするなあ
Re: (スコア:0)
比べる対象が間違ってる。
ASCIIだけ使ってればリスクゼロ。
UTF-8を使うとリスクゼロじゃなくなる。
これを、
> しょもないことを気にするなあ
と考える君はエンジニアに向いてない。
他のまともなエンジニアに迷惑をかける前に、リスク評価もロジカルな思考も不要な職業に転職することをおすすめする。
Re: (スコア:0)
具体的なリスクになってない、やり直し。
リスクがあるからリスクがあるんだってそれただのトートロジーだから。
Re: (スコア:0)
みんな「論理名」と「物理名」を区別する事に慣れちゃってると思うんよな。
予期しない場所で日本語を見かけると「論理名がなぜここに！？」と驚いちゃうし、不安になるかもね。
あと正規表現 /[\w_]+/ とか /\b/ とかで対応できないのも、しばしばgrepに命を救われてきた
歴戦の技術者にとってはストレスの材料になると思う。
Re: (スコア:0)
コメントとコードが一目でわかる、というのは非ラテン文字圏のメリットだと思うんよね
母語で変数名関数名を書いたらニュアンスの細かいところとかが気になったりもするし
なので俺も分けとく方がいいと思う
Re: (スコア:0)
君の正規表現の認識が古い
Re: (スコア:0)
へんなレスがついてる(;´Д`)なにこれ
Re: (スコア:0)
複数形とかキャメルケースで悩むならまだありかもだが全角なんてとんでもない！
データベースオブジェクトの命名規約
https://qiita.com/genzouw/items/35022fa96c120e67c637 [qiita.com]
Re: (スコア:0)
その動作保証されてて、日本人的に分かりやすくて、可読性という意味でメンテしやすいはずの方法を誰も使ってない理由を考えなかったのかな。
もしかして、こんな素晴らしい方法を考えたボクちゃんが天才で、今までこれに気づかなかった奴らは全員無能、とか思っちゃったのかな？
Re: (スコア:0)
たまーにおるよな、こういう自分の書いた狭い範囲のことしか見えてなくてシステム全体とか外接先への影響とかへの思慮が足りてないやつ。
だいたいすぐ帰任になって受け入れの手間だけ取らされるからマジで迷惑。