web-dev-qa-db-ja.com

あなたが従わざるを得なかった最も奇妙なコーディング標準ルールは何でしたか？

この質問 を聞いたとき、私はほとんど常に明確な答えを得ました。はい、コーディング標準が必要です。

あなたが従わざるを得なかった最も奇妙なコーディング標準ルールは何でしたか？

そして最も奇妙なことは、おかしい、最悪、または単なる奇妙なことを意味します。

それぞれの回答で、どの言語、あなたのチームの規模、そしてそれがあなたとあなたのチームを引き起こした悪影響に言及してください。

coding-style
173
Brian R. Bondy

Javaインスタンス変数にm_プレフィックスを付け、Java静的変数にg_プレフィックスを付けなければならない、ほとんどの非Javaメモ帳以外を使用してJavaを開発する方法を知らなかったCおよびC++開発者によって永続化された、私がこれまでに対処しなければならなかったばかげた作業！

静的なものからメソッド名まですべてにm_を付ける以外は実際に誰もこれに従わなかったことを除いて...

2
user177800

古いc＃コーディング標準では、巨大で見苦しいコメントブロックを使用する必要がありました。 Code Completeでは、 Steve McConnell がいコメントマクロの典型的な例を示しています。それ。ほぼ完全に一致。

これについての最悪なことは、c＃が既に優れた（そして比較的控えめな）コメントをサポートしている言語であるということでした。

次のようなものが得られます。

/// <summary>
/// Add an item to the collection
/// </summary>
/// <parameter name="item">The item to add</parameter>
/// <returns>Whether the addition succeeded</returns>
public bool Add(int item) { ... }

これは次のようになります。

// ########################################################## //
/// <summary>
///     Add an item to the collection
/// </summary>
///     IN:  <parameter name="item">The item to add</parameter>
///     OUT: <returns>Whether the addition succeeded</returns>
// ########################################################## //

StackOverflowの構文の強調表示では、デフォルトのVSテキストスキームと同様に、＃記号が明るい緑色であり、網膜の圧倒的な違反につながるため、正義ではありません。

著者は、以前のC/C++の試みから作者が本当に好きだったとしか思えません。問題は、自動プロパティが2つしかない場合でも、画面スペースの約50％を占有し、大きなノイズを追加することでした。追加の//行もR＃のリファクタリングサポートを台無しにしました。

コメントマクロを捨てた後、Visual Studioの既定のc＃コメントスタイルに戻したスクリプトを使用して、コードベース全体をスパンキングしました。

2
Mark Simpson

私が今までに耐えなければならなかった最悪のコーディング標準は、非常識なインデントでした。

コードは元々、60x80文字のグリーンスクリーンターミナルを使用してメインフレームで記述されていました（これはかなり前のことです）。これらのデフォルトのタブサイズは8文字でしたが、当時のプログラマーは大きすぎると判断しました-画面自体は80文字しか表示されなかったため、8文字のタブは多くのスペースを無駄にしました。

そこで彼らは、コードのインテントサイズを4文字に設定することにしました。

十分に公平だとあなたは言います。ただし、タブサイズを変更してもそれは行われませんでした。最初のインデントを4つのスペースにし、2番目のインデントを1つのタブ文字にするなど、4つのスペースとタブ文字の追加を交互に繰り返すことで、それを実現しました。

彼らは緑色の画面端末に固執しているが、これは大丈夫だった。奇妙ですが、結構です。

本当の混乱は、開発チームが新しいWindows PCを手に入れたときに始まりました。

彼らが選んだPCエディターのタブサイズは4文字に設定されていたため、コードが読み込まれると、インデントはいたるところにありました。

一部の開発者はまだ緑色の画面を使用しているため、インデントを修正できませんでした。そのため、1年ほど、チーム全体をPCに移行するのに時間がかかったため、どちらかの環境（またはより頻繁に、両方）。

1
Spudley

COBOLの時代には、コメントに3つのアスタリスクを使用する必要がありました（COBOLでは、列7に1つのアスタリスクしか必要ありません）。これをチェックするプリコンパイラもあり、3つのアスタリスク以外を使用した場合はプログラムをコンパイルしません。

1
Patrick Cuff

私が専門的に使用した最初の言語は4Dでした。 <>で始まるプロセス間変数、プレフィックスなしのプロセス変数、および$で始まるローカル変数をサポートしていました。これらすべてのプレフィックス（またはその欠如）は、変数のスコープを決定するためにコンパイラー/インタープリターによって使用されます。

実際の奇妙なコーディング標準は、ある種のハンガリー記法でした。キャッチは、変数のタイプに基づいて変数に名前を付ける代わりに、スコープに従って変数にプレフィックスを付ける必要があったことです。

スコープがプレフィックスによって決定される変数には、冗長な情報をプレフィックスとして付ける必要がありました！

なぜこのようにならなければならないのか、基準の責任者に敢えて尋ねることはありません...

1
3Doubloons

キーワードthisを単純に使用できる場合は、グローバル変数の前に_またはm_を使用します。グローバル変数にアクセスする必要がある場合...

1
Patrick Desjardins

私の最後の仕事では、私のスーパーバイザーは常にマーフィーの法則を施行しました：

「うまくいかないものはすべてうまくいかないでしょう。」

私はそれが原因だったと思うので、コードなどの簡単な修正を怠ることはありませんでした。そして今、私は常にそのフレーズを頭の中に持っています。

1
Carlo

奇妙なことは「これはC++でコーディングする必要がある」でした。おそらく、私は自分の専門知識のために雇われています。私の専門家の意見が、別の言語が仕事をより良くするだろうと言ったら、その他の言語が使用されるべきです。どのツールを使用すべきかを伝えることは、自動車整備士にメトリックレンチしか使用できないことを伝えることとほぼ同じです。そして、唯一のレンチ。

1
JUST MY correct OPINION

頭字語の大文字

DOキャメルケース識別子の最初のワードを除く2文字の頭字語の両方の文字を大文字にします。

System.IO
public void StartIO(Stream ioStream)

DO頭字語の最初の文字だけを、キャメルケース識別子の最初の単語を除く3文字以上で大文字にします。

System.Xml
public void ProcessHtmlTag(string htmlTag)

DO NOTキャメルケース識別子の先頭に、その長さにかかわらず、頭字語の文字を大文字にします。

1
nobar

私の上司は、enumの代わりに定数を使用することを主張しましたが、理由を与えることはなく、すべてのシナリオで、enumを使用する方が理にかなっています。

しかし、より良い方法は、すべてのテーブル名が単数形であると主張し、コード内のクラスも単数形にすることでした。しかし、ユーザーやグループなどのオブジェクトを表すだけでなく、テーブルも表し、そのテーブルのすべてのCRUDと他の多くのアクションを含んでいました。しかし、待ってください、まだあります！また、新しい列を追加したが新しいプロパティを追加したくない場合に備えて、列名でインデクサーを使用してプロパティを取得できるように、パブリックに表示される名前/値コレクションを含める必要がありました。意味をなさないだけでなく、コードに大きなパフォーマンスヒットをもたらす他の「する必要がある」ことがたくさんありました。私はそれらをすべて指摘しようとすることができましたが、コードはそれ自体を語っていますが、悲しいことに、これは古いアーカイブフォルダから取り出したUserクラスのほぼ正確なコピーです：

public class Record
{
    private string tablename;
    private Database database;

    public NameValueCollection Fields;

    public Record(string TableName) : this(TableName, null) { }
    public Record(string TableName, Database db)
    {
        tablename = TableName;
        database = db;
    }

    public string TableName
    {
        get { return tablename; }
    }

    public ulong ID
    {
        get { return GetULong("ID"); }
        set { Fields["ID"] = value.ToString(); }

    }

    public virtual ulong GetULong(string field)
    {
        try { return ulong.Parse(this[field]); }
        catch(Exception) { return 0; }
    }

    public virtual bool Change()
    {
        InitializeDB(); // opens the connection
        // loop over the Fields object and build an update query
        DisposeDB(); // closes the connection
        // return the status
    }

    public virtual bool Create()
    {
        // works almost just like the Change method
    }

    public virtual bool Read()
    {
        InitializeDB(); // opens the connection
        // use the value of the ID property to build a select query
        // populate the Fields collection with the columns/values if the read was successful
        DisposeDB(); // closes the connection
        // return the status    
    }
}

public class User
{
    public User() : base("User") { }
    public User(Database db) : base("User", db) { }

    public string Username
    {
        get { return Fields["Username"]; }
        set
        {
            Fields["Username"] = value.ToString(); // yes, there really is a redundant ToString call
        }
    }
}

この二重投稿の場合、申し訳ありませんが、最初は人間ではないかもしれません。または、サイトに投稿するコードの質に制限があるかもしれません。

1
Brian Surowiec

「コンパイラを書いた人はおそらくあなたよりもはるかに賢いので、何か賢いことをしようとしないでください」というのが、あるガイドラインドキュメントの言葉です（まったく文字通りではありません）。

0
Niklas Winde

メンバー変数に_を後付けします。例えば.

int numberofCycles_;

これは、2、3人の開発者によるオープンソースプロジェクトのC++で行われました。主な副作用は、名前の最後に到達するまで変数がクラススコープを持っていることを知らなかったことです。私が以前に考えたことはありませんでしたが、明らかに逆向きです。

0
Jason Sundram