アカウント名:
パスワード:
「もうやらなくてもいい昔のコーディング規約」かと。
ええ、もちろん大昔の話ですよ?
このお題を見て、てっきりFortranの桁揃えのことかと。メインフレームメーカーは7桁目に縦線の入ったコーディング用紙を供給していましたね。フローチャートのテンプレートも供給していた。当時は富士通を使っていたので、FACOMってロゴ入りだった。
FACOMのFortranのテキストにFortranの歌も載っていたな。おおブレネリの替え歌。ヤーッフォーッフォートランランランてやつ。
Fortranの歌といえば、20年ほど前に口の悪い友人はコウガマンの替え歌を教えてくれました。 「要らん使わん、フォートランー」てやつ。
プログラミングをしない私にはなんのことか分かりませんでした。
ていうか、たぶん今となってはコウガマン自体がセピア色の想い出。そもそもこのセピア色ってのが銀塩写真をある程度知らないと意味不明なんで、今時の若い者はきっと使わない言葉なんでしょう。
だからなぜセピア色なのか分かってんのか、ってこと。なぜその色なのか理解せず単に記号としてしか知らないからそういう発言が出るのではないかな?写真に写るときに「ピース」とか言ってVサインしたりするようなものだ。それに、銀塩写真に親しんでいた人が今時のデジタルカメラに疎いと決めつけるというのは愚かさを誇示することだよ。
で、そうやって本来の意味が忘れられた手順が書き物にだけ残って、意味のない縛りになって現役世代を苦しめると。#1560126のACみたいなのが年を取ると意味を考えず「決まってるから」と変なルールを押しつけるんだろうな。
断面を斜めに引いた線を見ながらそろえますよ。
でも、「コーディング規約⊂コーディングテクニック」の様な気もします。 それなりの合理性が有るノウハウや、バグの作り込みの原因を分析結果を元に、決められたのが、コーディング規約な訳で……ま、「規約」なるモノの常として、大概の場合、決められた、その時から、形骸化が始まる訳ですが。
変更した部分はコメントアウトして残すこと。
それと変更した日付と変更した人の名前を残すってのがありましたねー。2004年ごろの話ですけどね!#CVSやSubversionが今ほど普及していなかった頃の話#多分今も普及してないだろうけど、あの部署
CVS で管理しているところでもそんなのはありましたけどね。 何のための CVS なのかと……。
「うちでは変更をCSVで管理しているんだ。」(ああ、CVSか… subversionにすれば良いのに。)
っhistory.csv
野暮ですがいちおうコメントしますと、そういう連中が言う「管理」は非常にしばしば、管理になってない恐れが有るので最初から眉唾しとくべきです。
というのは、たとえばバージョン管理についていえば、
「xx月xx日。by xxx君。xxxという修正をおこなった」というコミットログみたいな情報は残って(=管理して)いるんだけど、肝心のファイルの「内容」をバージョン毎に保存していなくて、過去の版に戻すなんて神業は不可能!どうしてもやりたくなったら、ログのxxx君を呼び出して記憶を手繰らせる!
…なんてことがよく有るんで。
老人に同情するならば、悪い(あえて逆説的にいいます)のはム
>変更した日付と変更した人の名前を残すってのがありましたねー。
GPLv2
2-a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.2-a) あなたがそれらのファイルを変更したということと変更した日時が良く分かるよう、改変されたファイルに告示しなければならない。
2-a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
2-a) あなたがそれらのファイルを変更したということと変更した日時が良く分かるよう、改変されたファイルに告示しなければならない。
誰も守ってないと思うけどな
転職したらそんな職場だった。修正コメントであふれかえって、ただでさえ可読性が低い汚いソースがよけいに読みにくくしてしかたない。もう辞めたい。。。
> 同様に可読性を損なうコーディング規約に「タブではなくスペース4文字でインデント」がありますね。
おや?
スペースインデントって結構使ってるんですけど、NGだったんですか・・・ (+_+)
個人的には可読性を高めるためにスペースを結構多用してます。
スペースならどのエディタで開いてもインデントの深さが一緒になるので、
違うエディタで開いたり、他の人の画面でコーディングをチェックしてあげる時
タブだと設定によって崩れて見えて読みにくいんですもん
# タブでもスペースでも、2~4文字がちょうどいい人です# ネストの深さや種類によって、2文字だったり4文字だったり# はたまたタブだったりで、結構いい加減ですが (^-^;
僕はたいていの言語で「スペース 4 文字でインデント」派です。
同様に可読性を損なうコーディング規約に「タブではなくスペース4文字でインデント」がありますね。この話を未だに「好みのエディタ」のような宗教論争と同列に扱う輩が多いことに辟易します。
インデントをタブにするかスペースにするかとか、何桁にするかとかって、まさに「『好みのエディタ』のような宗教論争と同列」だと思っているのですが、何が違うのでしょうか。どちらも、選択肢がいろいろあり、どれも一長一短で完璧な解はなく、結局好みの問題だという点でよく似ていると思います。
> 何が違うのでしょうか。
インデント論争は、文書構造の視覚的表現を失うリスクの有無という観点から、本質的にどのエディタでもリスクに差がない(と思われる)エディタ論争と異なります。
ソースコードにおけるインデントとは、プログラムの文書構造を視覚的に表現するための手段です。視覚的に表現できれば何でも良いのでタブでも空白4文字でも8文字でも本来であれば問題ありません。しかしながら多くの場合、繰り返し流用や保守作業を続けていくと、空白で表現されたインデントは崩れやすく、コードブロックの判別が難しくなる傾向があります。6文字や7文字といった切りの悪い数の空白のインデントが散在し始めると、どこまでを一つのブロックと判断してよいのか分からなくなり、可読性を大きく損ないます。
タブの場合は、一文字でインデント一つを表現できるので保守性が向上します。また、タブが一文字削除されるとインデント一つ分大きく変動するので異常を即座に見つけやすいという利点もあります。
タブの表現がエディタによっては空白4文字か8文字の違いがあるので見た目が変わってよろしくない、なので空白4文字でインデントせよ、という主張がありますが、私は同意できません。上述のように、インデントとはプログラムの文書構造を表現するものであって、外観を表現するものではありません。8文字の環境の方は、8文字字下げされていれば、それがコードブロックを意味していると理解すればよいのであって、下げられたカラム数が8なのか4なのかはどちらでもよいからです。
一方で、ソースコードの中には、視覚的な位置が重要な意味を持つ記述もあります。例えば構造体配列を用いたテーブルの定義などで、各メンバの初期化子の頭を揃えて記述して可読性を向上させるなどのケースです。このような場合にこそ空白を用いて頭揃えすべきで、タブは絶対に用いるべきではありません。仮にタブを用いて頭揃えした場合、タブ位置の異なる環境では、テーブルが大きく崩れて可読性を損なうでしょう。
そもそも、プレーンテキストでソースコードを記述しなければいけない以上、文書構造と外観を切り離せないのは最早どうしようもなく、このような議論がつきまとうのは宿命とも言えるのですが、明日から全員Cソースを XML で書けと言って世のC言語エンジニア全員を敵に回すのもよろしくないでしょうし、しょうがないので現場ではうるさくは言わないようにはしていますが。
とりあえず1回pythonでツール書かせようぜインデントが等しい範囲がブロックになるからおかしなインデントしてると思い知るよ
>タブ幅を8以外に変えられないエディタがあるとか、そんな事情ですかね。
タブ幅を変えられることを知らない初心者があるとか、未だに手動でインデントを付けてる初心者があるとか、そんな事情では。
まあ普通は
ぐらいでいいと思うんだけどなあ。
すくなくとも「スペースにしたから可読性が上がる」ってのはちょっと違うだろと。オレの目には四文字分のスペースも四文字幅のタブも、見た目は同じにしか見えません。;-)
リーナスおじさんの「タブ幅は8桁で決まり!」主張 [linux.or.jp]を誰かフォローしとくべきでは?
#この話題はおじさんホイホイなんだし
> リーナスおじさんの「タブ幅は8桁で決まり!」主張を誰かフォローしとくべきでは?
深いネストはロクなもんじゃない、同感ですね。3段階とまでは言わないですが、5段以上になるケースは僕の場合は希です。
# 確かに論理構造の劣悪さに着目しないで、単なるプログラミングスタイルの問題と# 捉えている人は多いですね。
うちではハードタブによるインデントは禁止にしますた。インデンテーションの処理自体はエディタがやってくれるので手間は変わらず、サーバ上でviだのlessだのを使わざるを得ない場合でもインデントが狂わなくて、少し幸せになれました。
>もう辞めたい。。。その気持ちは嫌と言うほど理解できるが我慢しろ。日本のIT業界なんてそんな所ばかりだ。
技術力があるって触れ込みの所でもそんな有様だ。おそらく7~8割くらいはそのレベルだし、残りの2~3割にしても「それよりはマシ」の域は出てない。
そんなソースに出会ったことはありますが・・・そもそも、作り自体が悪いのもあって一から作り直しました。コメント?バグつぶしのコメントをとっておいてもしょうがないでしょう。仕様のコメントなら大歓迎ですが。
親コメントとは別人ですが、数年前に入社以来同じ悩みを抱えてました。やっぱりどこもそんな感じなんですかね…。
おつむがある時点で止まってらっしゃる人々(個人または集団)では、新しい画期的なツールなんてものは存在を信じてもらえないし、現物見せようとしても見るのも渋るし、仮に見せるところまでいけても、それの振る舞いが安定していることを信じてくれない。「偶然動いたんだろ。いつでも動くかどうかなんて信用できない」と。
まるで幽霊か宗教のような扱いを受けます。
もっとも本当に幽霊宗教に染まってるのはソッチのほうなのは皆さんご存知の通りです。そういうところに限って、逆に自分らが今まで使ってたツールについては、それがどんなに怪しげなものであろうとも「信頼」します。つまり
>>変更した部分はコメントアウトして残すこと。
変更部分どころか、その関数の処理概要を書く人いませんでした?informix 4GLなんてものを使っているプロジェクトでPMやってたとき、設計書の仕様よりコメントのほうが実態に近いので、ソース読んで関数の関連とコメント行を抽出する管理PGを作らせようかと思ったことがあります。途中でそれどころじゃなくなったけど。
私、コメントで処理概要を書いてから、それをプログラムに直す人です。
>変更部分どころか、その関数の処理概要を書く人いませんでした?今だと広く普及していますね。
javadocとかで。
>設計書の仕様よりコメントのほうが実態に近いので、これは、………
#だから設計書なんてものを後生大事にする必要はないとアレほどブツブツ...##これだからプログラミングをやったことのないジジイどもはブツブツ...
私は無くしたわけではないけど、受託開発の見積りでドキュメントをアンバンドルしてます。
開発と同じコストがかかるドキュメントを要求されるケースはあまりないです。ほとんどは(追加費用がかからない) README 程度、細かくてもユーザマニュアルや導入ガイドまで。関数やプログラムの説明を求めるような詳細ドキュメントを要求されたことはないですね。
>開発と同じコストがかかるドキュメントを要求されるケースはあまりない
そりゃそうだろう。「だから」、ドキュメントを請求されたうえで、その御代は値切られるんだよorz
野蛮な話だが、まあこんなことも有るわけですよ。力関係がおかしい場合には。
そういえば、一番最初に提唱された自由経済主義とは、契約する両者がともに「十分な情報を受け取ったうえで」契約をどうするか判断する、というスタイルを指すのだそうです。が、その情報じたいにお値段をつけられて「払えるなら渡すよ」とか色々ややこしい縛りが入ってきた場合、これも自由経済主義だと呼べるんだろうか??
自分が何時代に居るのか最近判らなくなってきています。
新人が「フローチャートの書き方がよく分からなかったのでもう少し勉強して書けるようになりたいです」という日々の報告を上げてくるような組織のそばで働いています。やめさせた方がいいですか?いや、直接教育担当ではないので、口出ししないように言われているのですが。
もちろん、オブジェクト指向だ何だといっても、中では順序だって処理する部分が絶対にあるわけで、その部分の処理の流れを図で示せる能力は必要だと思いますが....新人が悩んで自信を無くしかけるほどまで深く掘り下げる場所じゃないとおもうんですよね。
>直接教育担当ではないので、口出ししないように言われている
その身分制度(の過剰さ)も、かなりおおきな害悪なので、どうにかする努力をしたほうがいいです。
問題指摘なんてのは「社内で一番最初に気づいた奴が言う(という権利が有る)」ことにするのが一番です。それを採用するかどうかはまた別としても、まず言う権利くらい全員に与えないと、なにしに「会社」に大勢が雁首揃えてるのか判りません。
>フローチャート
無数にある実装(/設計)上必要なもののうちのごくごく一部でしかないですね。たまたま一本の長い流れが発生したときにそれを記述しやすいというだけなので、フローチャート自体がデザパタとかと同様に「特定の状況では有効、別の状況では逆効果」というものでしかないです。そういう状況になったときには「そういやフローチャートなんてものもあったな」と押入れから引っ張り出せばいいものであって、常に机に置いておくほどのもんじゃないです。
そして、他の人がいってるように並列処理も書けないし、OOPを引き合いに出すまでもなく状態変化やマルチ状態も書けない。つまり「コンテキスト」を記述する能力が無いんですよねフローチャートには。バグは処理そのものよりも処理と絡むコンテキスト(の誤用)に宿ることが多いので、それが見えにくいフローチャートはあんまり役立たないことが多いなあ。つまり本当に数少ない特定の場面でしか有効ではなく、大抵は邪魔。
フローなんぞより、データ構造のほうが余程大事ですし、データ構造を基準に見れば全体が判る「ように設計」すればますますバグりにくくなります。自社を倒産させたくないならば狙うべきはそっちですね。
フローチャートは必要ないが、フローチャートを書ける能力は必要。(他の表記法も同様)
同意
フローチャートなんて無くても困らない必要になるのは、やたらとフローチャートに拘る年代の方に見せる資料を作成する時かなー。
最近の開発環境でフローチャート書けるだろうか。並列処理は書けないのよね、あれ。
> プログラムを書くために必要な論理思考を伴わない人(学生)というのが結構いるのですよ。
御意。居りますなあ。一年位でアプリからカーネルまで出来る様になって欲しいのですが、前途遼遠・・・
> でも、フローチャート以外の代替案(現場でも使いそうなもの)ってどういうのがいいのだろうか…
NSチャート、PAD位しかチャートを知らないのですが、どれも一長一短がありますね。しかし本来はコードを書く前にチャート等で論理構造を検討する必要がある人達も時代の流れでチャート等を書かなくなり、その帰結として「なんじゃ?こりゃ?」なコードの大量生産、これが近年の傾向では無いでしょうか。もっとも、チャート等で論理構造の検討を行うとか、エレガントなコードが書ける人も求めると言うのが(特にお金の面で)難しくなっている事も理由だとは思いますが。プロジェクト管理で品質について考える場合でも、通常は表層的なバグ数のカウントに終始している訳で、コードの安定性の様なものはバグの原因にさえならなければ無視、無視出来ない場合は大炎上ですね(少なくとも僕が絡んでいる所ででは、ですが)。
ルータ構成ツールにステートチャート(UMLのではなくて、ステートマシンの記述の方)の作成がプログラミングになるものがあります。エレガントなコードを志向するのが死に筋なら、その様なアプローチもありなのかな、と思っています。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
てっきり (スコア:5, おもしろおかしい)
「もうやらなくてもいい昔のコーディング規約」かと。
ええ、もちろん大昔の話ですよ?
Re:てっきり (スコア:3, 興味深い)
このお題を見て、てっきりFortranの桁揃えのことかと。メインフレームメーカーは7桁目に縦線の入ったコーディング用紙を供給していましたね。フローチャートのテンプレートも供給していた。当時は富士通を使っていたので、FACOMってロゴ入りだった。
FACOMのFortranのテキストにFortranの歌も載っていたな。おおブレネリの替え歌。
ヤーッフォーッフォートランランランてやつ。
Re:てっきり (スコア:2)
Fortranの歌といえば、20年ほど前に口の悪い友人はコウガマンの替え歌を教えてくれました。
「要らん使わん、フォートランー」てやつ。
プログラミングをしない私にはなんのことか分かりませんでした。
ていうか、たぶん今となってはコウガマン自体がセピア色の想い出。そもそもこのセピア色ってのが銀塩写真をある程度知らないと意味不明なんで、今時の若い者はきっと使わない言葉なんでしょう。
Jubilee
Re:てっきり (スコア:2)
だからなぜセピア色なのか分かってんのか、ってこと。なぜその色なのか理解せず単に記号としてしか知らないからそういう発言が出るのではないかな?写真に写るときに「ピース」とか言ってVサインしたりするようなものだ。それに、銀塩写真に親しんでいた人が今時のデジタルカメラに疎いと決めつけるというのは愚かさを誇示することだよ。
で、そうやって本来の意味が忘れられた手順が書き物にだけ残って、意味のない縛りになって現役世代を苦しめると。#1560126のACみたいなのが年を取ると意味を考えず「決まってるから」と変なルールを押しつけるんだろうな。
Jubilee
Re: (スコア:0)
ええ、カップラーメンの汁が飛んで読み取りエラーする紙テープでしたよ。
やっぱCOBOL (スコア:0)
最新のCOBOL言語仕様がどうなってるか知らないけど、今じゃHOST系でも
桁位置合わせ(A欄、B欄)の意味しかないし。
前はまじめに行番号もコーディングしておくと、
カードぶちまけたときの手SORT時に役にたったけどね。
そういう意味じゃテープ(紙のね)は落としても散らばらないから、
FALLSAFEではあったな。
FORTRANなんかだと、カードぶちまけたときはどうしてたんだろう。
Re: (スコア:0)
断面を斜めに引いた線を見ながらそろえますよ。
Re: (スコア:0)
Re:てっきり (スコア:2, すばらしい洞察)
でも、「コーディング規約⊂コーディングテクニック」の様な気もします。
それなりの合理性が有るノウハウや、バグの作り込みの原因を分析結果を元に、決められたのが、コーディング規約な訳で……ま、「規約」なるモノの常として、大概の場合、決められた、その時から、形骸化が始まる訳ですが。
Re:てっきり (スコア:2)
変更した部分はコメントアウトして残すこと。
それと変更した日付と変更した人の名前を残すってのがありましたねー。
2004年ごろの話ですけどね!
#CVSやSubversionが今ほど普及していなかった頃の話
#多分今も普及してないだろうけど、あの部署
Re:てっきり (スコア:3, 興味深い)
これは今でもあっちこっちで見受けますよねー。
で、変更した人に詳細を聞きに行こうとしたら8割の確率で
「あ。その人とっくに辞めてますよ」 orz
だから、あんまり役に立たないんだよねー。
# ちなみに私も今は「とっくに辞めてますよ」の側だから、これ以上、つっこまない(笑)
clausemitz
Re:てっきり (スコア:1)
CVS で管理しているところでもそんなのはありましたけどね。
何のための CVS なのかと……。
Re:てっきり (スコア:2)
「うちでは変更をCSVで管理しているんだ。」
(ああ、CVSか… subversionにすれば良いのに。)
っhistory.csv
HIRATA Yasuyuki
Re:てっきり (スコア:1)
-- 哀れな日本人専用(sorry Japanese only) --
Re: (スコア:0)
野暮ですがいちおうコメントしますと、
そういう連中が言う「管理」は非常にしばしば、管理になってない恐れが有るので最初から眉唾しとくべきです。
というのは、たとえばバージョン管理についていえば、
「xx月xx日。by xxx君。xxxという修正をおこなった」
というコミットログみたいな情報は残って(=管理して)いるんだけど、
肝心のファイルの「内容」をバージョン毎に保存していなくて、
過去の版に戻すなんて神業は不可能!
どうしてもやりたくなったら、ログのxxx君を呼び出して記憶を手繰らせる!
…なんてことがよく有るんで。
老人に同情するならば、悪い(あえて逆説的にいいます)のはム
Re:てっきり (スコア:1)
>変更した日付と変更した人の名前を残すってのがありましたねー。
GPLv2
誰も守ってないと思うけどな
Re: (スコア:0)
転職したらそんな職場だった。
修正コメントであふれかえって、ただでさえ可読性が低い汚いソースがよけいに読みにくくしてしかたない。
もう辞めたい。。。
Re:てっきり (スコア:1)
同様に可読性を損なうコーディング規約に「タブではなくスペース4文字でインデント」がありますね。この話を未だに「好みのエディタ」のような宗教論争と同列に扱う輩が多いことに辟易します。
格差社会ニッポンを変える!
貸し渋り・はがしの温床、大銀行の厳正審査をやめさせよう!
Re:てっきり (スコア:2)
> 同様に可読性を損なうコーディング規約に「タブではなくスペース4文字でインデント」がありますね。
おや?
スペースインデントって結構使ってるんですけど、NGだったんですか・・・ (+_+)
個人的には可読性を高めるためにスペースを結構多用してます。
スペースならどのエディタで開いてもインデントの深さが一緒になるので、
違うエディタで開いたり、他の人の画面でコーディングをチェックしてあげる時
タブだと設定によって崩れて見えて読みにくいんですもん
# タブでもスペースでも、2~4文字がちょうどいい人です
# ネストの深さや種類によって、2文字だったり4文字だったり
# はたまたタブだったりで、結構いい加減ですが (^-^;
Re: (スコア:0)
後、プログラマのレベルが違いすぎると、ほんの2行程度の内容が理解できなかったりする...
Re:てっきり (スコア:2)
僕はたいていの言語で「スペース 4 文字でインデント」派です。
インデントをタブにするかスペースにするかとか、何桁にするかとかって、まさに「『好みのエディタ』のような宗教論争と同列」だと思っているのですが、何が違うのでしょうか。どちらも、選択肢がいろいろあり、どれも一長一短で完璧な解はなく、結局好みの問題だという点でよく似ていると思います。
Re:てっきり (スコア:1)
> 何が違うのでしょうか。
インデント論争は、文書構造の視覚的表現を失うリスクの有無という観点から、本質的にどのエディタでもリスクに差がない(と思われる)エディタ論争と異なります。
ソースコードにおけるインデントとは、プログラムの文書構造を視覚的に表現するための手段です。視覚的に表現できれば何でも良いのでタブでも空白4文字でも8文字でも本来であれば問題ありません。しかしながら多くの場合、繰り返し流用や保守作業を続けていくと、空白で表現されたインデントは崩れやすく、コードブロックの判別が難しくなる傾向があります。6文字や7文字といった切りの悪い数の空白のインデントが散在し始めると、どこまでを一つのブロックと判断してよいのか分からなくなり、可読性を大きく損ないます。
タブの場合は、一文字でインデント一つを表現できるので保守性が向上します。また、タブが一文字削除されるとインデント一つ分大きく変動するので異常を即座に見つけやすいという利点もあります。
タブの表現がエディタによっては空白4文字か8文字の違いがあるので見た目が変わってよろしくない、なので空白4文字でインデントせよ、という主張がありますが、私は同意できません。上述のように、インデントとはプログラムの文書構造を表現するものであって、外観を表現するものではありません。8文字の環境の方は、8文字字下げされていれば、それがコードブロックを意味していると理解すればよいのであって、下げられたカラム数が8なのか4なのかはどちらでもよいからです。
一方で、ソースコードの中には、視覚的な位置が重要な意味を持つ記述もあります。例えば構造体配列を用いたテーブルの定義などで、各メンバの初期化子の頭を揃えて記述して可読性を向上させるなどのケースです。このような場合にこそ空白を用いて頭揃えすべきで、タブは絶対に用いるべきではありません。仮にタブを用いて頭揃えした場合、タブ位置の異なる環境では、テーブルが大きく崩れて可読性を損なうでしょう。
そもそも、プレーンテキストでソースコードを記述しなければいけない以上、文書構造と外観を切り離せないのは最早どうしようもなく、このような議論がつきまとうのは宿命とも言えるのですが、明日から全員Cソースを XML で書けと言って世のC言語エンジニア全員を敵に回すのもよろしくないでしょうし、しょうがないので現場ではうるさくは言わないようにはしていますが。
格差社会ニッポンを変える!
貸し渋り・はがしの温床、大銀行の厳正審査をやめさせよう!
Re:てっきり (スコア:1)
とりあえず1回pythonでツール書かせようぜ
インデントが等しい範囲がブロックになるから
おかしなインデントしてると思い知るよ
Re:てっきり (スコア:1)
タブにすると可読性が上がるような(上記の手間に見合う)何かがあるのでしょうか?
Re: (スコア:0)
というか、普通にやれば、そうなります。
最悪なのは、エディタをタブ8桁に設定して、スペース4文字とタブを混ぜる書き方。
んなことするなら、タブ4桁に設定しろっつーの。
自分好みに自動整形すりゃいいじゃんという話もありますが、
ホワイトスペースの変更が許されない場合もありまして・・・
Re:てっきり (スコア:1)
・自分好みの幅で表示できるからタブの方が優れている
・スペースを混ぜると破綻する
ってことですね。
> 最悪なのは、エディタをタブ8桁に設定して、スペース4文字とタブを混ぜる書き方。
タブ幅を8以外に変えられないエディタがあるとか、そんな事情ですかね。今時ないとは思いますが。
Re:てっきり (スコア:1)
>タブ幅を8以外に変えられないエディタがあるとか、そんな事情ですかね。
タブ幅を変えられることを知らない初心者があるとか、
未だに手動でインデントを付けてる初心者があるとか、
そんな事情では。
まあ普通は
ぐらいでいいと思うんだけどなあ。
すくなくとも「スペースにしたから可読性が上がる」ってのはちょっと違うだろと。
オレの目には四文字分のスペースも四文字幅のタブも、見た目は同じにしか見えません。;-)
異教徒どもめ (スコア:3, 興味深い)
リーナスおじさんの「タブ幅は8桁で決まり!」主張 [linux.or.jp]を誰かフォローしとくべきでは?
#この話題はおじさんホイホイなんだし
Re:異教徒どもめ (スコア:2)
> リーナスおじさんの「タブ幅は8桁で決まり!」主張を誰かフォローしとくべきでは?
深いネストはロクなもんじゃない、同感ですね。3段階とまでは言わないですが、5段以上になるケースは僕の場合は希です。
# 確かに論理構造の劣悪さに着目しないで、単なるプログラミングスタイルの問題と
# 捉えている人は多いですね。
Re:てっきり (スコア:1)
うちではハードタブによるインデントは禁止にしますた。
インデンテーションの処理自体はエディタがやってくれるので手間は変わらず、
サーバ上でviだのlessだのを使わざるを得ない場合でもインデントが狂わなくて、
少し幸せになれました。
Re: (スコア:0)
>もう辞めたい。。。
その気持ちは嫌と言うほど理解できるが我慢しろ。
日本のIT業界なんてそんな所ばかりだ。
技術力があるって触れ込みの所でもそんな有様だ。
おそらく7~8割くらいはそのレベルだし、
残りの2~3割にしても「それよりはマシ」の域は出てない。
Re:てっきり (スコア:2)
そんなソースに出会ったことはありますが・・・
そもそも、作り自体が悪いのもあって一から作り直しました。
コメント?
バグつぶしのコメントをとっておいてもしょうがないでしょう。
仕様のコメントなら大歓迎ですが。
Re: (スコア:0)
親コメントとは別人ですが、数年前に入社以来同じ悩みを抱えてました。
やっぱりどこもそんな感じなんですかね…。
Re: (スコア:0)
おつむがある時点で止まってらっしゃる人々(個人または集団)では、
新しい画期的なツールなんてものは
存在を信じてもらえないし、
現物見せようとしても見るのも渋るし、
仮に見せるところまでいけても、
それの振る舞いが安定していることを信じてくれない。
「偶然動いたんだろ。いつでも動くかどうかなんて信用できない」と。
まるで幽霊か宗教のような扱いを受けます。
もっとも本当に幽霊宗教に染まってるのはソッチのほうなのは皆さんご存知の通りです。
そういうところに限って、逆に自分らが今まで使ってたツールについては、
それがどんなに怪しげなものであろうとも「信頼」します。つまり
ソース内コメント (スコア:1)
>>変更した部分はコメントアウトして残すこと。
変更部分どころか、その関数の処理概要を書く人いませんでした?
informix 4GLなんてものを使っているプロジェクトでPMやってたとき、
設計書の仕様よりコメントのほうが実態に近いので、ソース読んで
関数の関連とコメント行を抽出する管理PGを作らせようかと思った
ことがあります。途中でそれどころじゃなくなったけど。
ええ、もちろん大昔の話ですよ?
Re:ソース内コメント (スコア:1)
私、コメントで処理概要を書いてから、それをプログラムに直す人です。
the.ACount
Re: (スコア:0)
>変更部分どころか、その関数の処理概要を書く人いませんでした?
今だと広く普及していますね。
javadocとかで。
>設計書の仕様よりコメントのほうが実態に近いので、
これは、………
#だから設計書なんてものを後生大事にする必要はないとアレほどブツブツ...
##これだからプログラミングをやったことのないジジイどもはブツブツ...
Re:てっきり (スコア:1)
●ドキュメンテーション
頭痛のたねが無くなってすっきりです。
Re:てっきり (スコア:1)
私は無くしたわけではないけど、受託開発の見積りでドキュメントをアンバンドルしてます。
開発と同じコストがかかるドキュメントを要求されるケースはあまりないです。ほとんどは(追加費用がかからない) README 程度、細かくてもユーザマニュアルや導入ガイドまで。関数やプログラムの説明を求めるような詳細ドキュメントを要求されたことはないですね。
の
Re: (スコア:0)
>開発と同じコストがかかるドキュメントを要求されるケースはあまりない
そりゃそうだろう。「だから」、ドキュメントを請求されたうえで、その御代は値切られるんだよorz
野蛮な話だが、まあこんなことも有るわけですよ。力関係がおかしい場合には。
そういえば、一番最初に提唱された自由経済主義とは、
契約する両者がともに「十分な情報を受け取ったうえで」契約をどうするか判断する、
というスタイルを指すのだそうです。
が、その情報じたいにお値段をつけられて「払えるなら渡すよ」とか色々ややこしい縛りが入ってきた場合、これも自由経済主義だと呼べるんだろうか??
Re: (スコア:0)
ググればたいていのことは解決する。
Re: (スコア:0)
自分が何時代に居るのか最近判らなくなってきています。
新人が「フローチャートの書き方がよく分からなかったのでもう少し勉強して書けるようになりたいです」という
日々の報告を上げてくるような組織のそばで働いています。やめさせた方がいいですか?いや、直接教育担当では
ないので、口出ししないように言われているのですが。
もちろん、オブジェクト指向だ何だといっても、中では順序だって処理する部分が絶対にあるわけで、その部分の
処理の流れを図で示せる能力は必要だと思いますが....新人が悩んで自信を無くしかけるほどまで深く掘り下げる
場所じゃないとおもうんですよね。
Re:てっきり (スコア:2, すばらしい洞察)
>直接教育担当ではないので、口出ししないように言われている
その身分制度(の過剰さ)も、かなりおおきな害悪なので、どうにかする努力をしたほうがいいです。
問題指摘なんてのは「社内で一番最初に気づいた奴が言う(という権利が有る)」ことにするのが一番です。
それを採用するかどうかはまた別としても、まず言う権利くらい全員に与えないと、なにしに「会社」に大勢が雁首揃えてるのか判りません。
>フローチャート
無数にある実装(/設計)上必要なもののうちのごくごく一部でしかないですね。
たまたま一本の長い流れが発生したときにそれを記述しやすいというだけなので、フローチャート自体がデザパタとかと同様に「特定の状況では有効、別の状況では逆効果」というものでしかないです。
そういう状況になったときには「そういやフローチャートなんてものもあったな」と押入れから引っ張り出せばいいものであって、常に机に置いておくほどのもんじゃないです。
そして、他の人がいってるように並列処理も書けないし、OOPを引き合いに出すまでもなく状態変化やマルチ状態も書けない。つまり「コンテキスト」を記述する能力が無いんですよねフローチャートには。バグは処理そのものよりも処理と絡むコンテキスト(の誤用)に宿ることが多いので、それが見えにくいフローチャートはあんまり役立たないことが多いなあ。つまり本当に数少ない特定の場面でしか有効ではなく、大抵は邪魔。
フローなんぞより、データ構造のほうが余程大事ですし、データ構造を基準に見れば全体が判る「ように設計」すればますますバグりにくくなります。自社を倒産させたくないならば狙うべきはそっちですね。
Re:てっきり (スコア:1)
フローチャートは必要ないが、フローチャートを書ける能力は必要。(他の表記法も同様)
the.ACount
Re:てっきり (スコア:1)
#フローチャート書いてる暇があったら、なんでもいいから動くもものを作った方が勉強になると思う。
Re: (スコア:0)
同意
フローチャートなんて無くても困らない
必要になるのは、やたらとフローチャートに拘る年代の方に見せる資料を作成する時かなー。
Re: (スコア:0)
最近の開発環境でフローチャート書けるだろうか。並列処理は書けないのよね、あれ。
Re: (スコア:0)
並列処理云々という前に、プログラムを書くために必要な論理思考を伴わない人(学生)というのが結構いるのですよ。
雛形(#include <stdio.h>~int main(...){...})だけとりあえず与えて、中に必要な流れを書いていくということをやらせると、
どういう手順でやっていったらいいかまるで考えられないというのがごろごろと。
だからとりあえず必要なことを列挙させ、線でつなげさせて必要なロジックを埋め込んでいってフロー化させる。
「いらないだろう」という人たちは、半ば無意識にでも「どういう手順でやっていったらいいか」がつなげられる人たちなんです。
並列云々へ行く前に、思考力を鍛えるためにはなんらかの形での目で見える形にするのが必要だと思います。
でも、フローチャート以外の代替案(現場でも使いそうなもの)ってどういうのがいいのだろうか…
Re:てっきり (スコア:2)
> プログラムを書くために必要な論理思考を伴わない人(学生)というのが結構いるのですよ。
御意。居りますなあ。一年位でアプリからカーネルまで出来る様になって欲しいのですが、前途遼遠・・・
> でも、フローチャート以外の代替案(現場でも使いそうなもの)ってどういうのがいいのだろうか…
NSチャート、PAD位しかチャートを知らないのですが、どれも一長一短がありますね。しかし本来はコードを書く前にチャート等で論理構造を検討する必要がある人達も時代の流れでチャート等を書かなくなり、その帰結として「なんじゃ?こりゃ?」なコードの大量生産、これが近年の傾向では無いでしょうか。もっとも、チャート等で論理構造の検討を行うとか、エレガントなコードが書ける人も求めると言うのが(特にお金の面で)難しくなっている事も理由だとは思いますが。プロジェクト管理で品質について考える場合でも、通常は表層的なバグ数のカウントに終始している訳で、コードの安定性の様なものはバグの原因にさえならなければ無視、無視出来ない場合は大炎上ですね(少なくとも僕が絡んでいる所ででは、ですが)。
ルータ構成ツールにステートチャート(UMLのではなくて、ステートマシンの記述の方)の作成がプログラミングになるものがあります。エレガントなコードを志向するのが死に筋なら、その様なアプローチもありなのかな、と思っています。
Re: (スコア:0)