アカウント名:
パスワード:
たとえば、文章の校正をする場合を考えると、文字が汚な過ぎると読み取るのに苦労して、内容のチェックどころではないでしょう。文字のきれい汚いは文章の内容とは関係ないはずですけど。
プログラムの場合も同じであり、にコーディングスタイルがいい加減だったり、変数名・関数名が内容とマッチしていなかったりした場合は、そちらの読解にばかりエネルギーが割かれて、プログラムの内容どころではなくなってしまうのでは無いでしょうか。
目立つノイズが消えると、本当の問題が見えてくる。
同意です。学生がもってきた英語の論文の原稿なおすときは、最初の1回の修正は、ほとんど「てにをは」的な修正ばかりです。まずはこれ直してまたもってこいと(または、言いたいことと意味が違ってしまった箇所があったら、別の表現を再提案しろと)。そういう修正だけで真っ赤になって読みにくいというのもありますし、学生の頭を整理させるのにも役立ちます。その後で、論理的な構成について本人の書きたかった事を確認しながら修正する作業に入ります。
>文字が汚な過ぎると読み取るのに苦労して、
その例えば不適切だ。#そもそも「文字の綺麗汚い」の問題は、ディスプレイで表示するに白プリンタで#打ち出すにしろプログラムでは通常起こらない。
たとえば縦書きか横書きか、ノートはB罫かA罫かはたまた原稿用紙か、紙面の大きさはA4かB5か。或いは電子データにする場合はプレーンテキストなのかMSワードなのか。
そういったことはなるべくなら統一されてる方が良い。
特にたとえば小説/ラノベの新人賞に投稿してくるなら、どの形式で提出しろと定めていてもおかしくはない。出版を前提にしたプロの場合は、印刷に対応できるフォーマットであることは重要だろう。また同じ社内で利用する書類なら、同じ報告書のフォーマットが定められているのは普通だろう。
しかし人間の可読性という点においては、それらはほとんど意味のない、どうでもいい話だ。
大抵、そういう酷いプログラマをターゲットに規約が作られるので、微に入り細に入りの膨大な規則を作ってしまいがちなんですよね・・・。結局守れる限界の量を超えてしまい、現実的には仕事を進めるためには誰も何も守らなくなるという逆効果を生みます。
コーディング規約を作る人間は自分の趣味や美意識を入れる欲望をできるだけ抑えて、コストとメリットのバランスだけで作るべき。
昔、Cでの開発案件で「変数名や関数名、ファイル名は(ローカル変数も含めて)全てDBに登録して払い出されたものを使う」というのにぶち当たったことがありましたが、そういう極端なのを除けばまあ大抵は概ね常識的な範囲で収まってましたしね。
コーディング規約に意味が無いのなら特に無視する理由もないし、コーディング規約に意味があるのなら特に守らない理由もない訳で。
もしくは、酷いプログラマはパージする事をお勧めする。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
目立つノイズが消えると、本当の問題が見えてくる。 (スコア:2)
たとえば、文章の校正をする場合を考えると、文字が汚な過ぎると読み取るのに苦労して、内容のチェックどころではないでしょう。文字のきれい汚いは文章の内容とは関係ないはずですけど。
プログラムの場合も同じであり、にコーディングスタイルがいい加減だったり、変数名・関数名が内容とマッチしていなかったりした場合は、そちらの読解にばかりエネルギーが割かれて、プログラムの内容どころではなくなってしまうのでは無いでしょうか。
Re:目立つノイズが消えると、本当の問題が見えてくる。 (スコア:2, 興味深い)
同意です。学生がもってきた英語の論文の原稿なおすときは、最初の1回の修正は、ほとんど「てにをは」的な修正ばかりです。まずはこれ直してまたもってこいと(または、言いたいことと意味が違ってしまった箇所があったら、別の表現を再提案しろと)。そういう修正だけで真っ赤になって読みにくいというのもありますし、学生の頭を整理させるのにも役立ちます。その後で、論理的な構成について本人の書きたかった事を確認しながら修正する作業に入ります。
Re:目立つノイズが消えると、本当の問題が見えてくる。 (スコア:1)
>文字が汚な過ぎると読み取るのに苦労して、
その例えば不適切だ。
#そもそも「文字の綺麗汚い」の問題は、ディスプレイで表示するに白プリンタで
#打ち出すにしろプログラムでは通常起こらない。
たとえば縦書きか横書きか、
ノートはB罫かA罫かはたまた原稿用紙か、
紙面の大きさはA4かB5か。
或いは電子データにする場合はプレーンテキストなのかMSワードなのか。
そういったことはなるべくなら統一されてる方が良い。
特にたとえば小説/ラノベの新人賞に投稿してくるなら、どの形式で提出しろと定めていてもおかしくはない。
出版を前提にしたプロの場合は、印刷に対応できるフォーマットであることは重要だろう。
また同じ社内で利用する書類なら、同じ報告書のフォーマットが定められているのは普通だろう。
しかし人間の可読性という点においては、それらはほとんど意味のない、どうでもいい話だ。
Re: (スコア:0)
Re: (スコア:0)
大抵、そういう酷いプログラマをターゲットに規約が作られるので、微に入り細に入りの膨大な規則を作ってしまいがちなんですよね・・・。
結局守れる限界の量を超えてしまい、現実的には仕事を進めるためには誰も何も守らなくなるという逆効果を生みます。
コーディング規約を作る人間は自分の趣味や美意識を入れる欲望をできるだけ抑えて、コストとメリットのバランスだけで作るべき。
Re: (スコア:0)
昔、Cでの開発案件で「変数名や関数名、ファイル名は(ローカル変数も含めて)全てDBに登録して払い出されたものを使う」というのにぶち当たったことがありましたが、そういう極端なのを除けばまあ大抵は概ね常識的な範囲で収まってましたしね。
コーディング規約に意味が無いのなら特に無視する理由もないし、
コーディング規約に意味があるのなら特に守らない理由もない訳で。
Re: (スコア:0)
もしくは、酷いプログラマはパージする事をお勧めする。