Объяснение соглашений об именах для классов, методов и переменных

Question

В настоящее время я учусь в университете, и они очень внимательно следят за своими стандартами.

Они сказали мне это:

Все классы должны начинаться с заглавной буквы. письмо

Корректное

public class MyClass {}

Некорректное

public class myClass {}
public class _myClass {}

Все методы должны начинаться с строчная буква

Корректное

public void doSomething() {}

Некорректное

public void DoSomething() {}
public void _doSomething() {}

все переменные должны начинаться с строчная буква

Корректное

string myString;

Некорректное

string MyString;
string _myString;

Тем не менее, в мой последний год программирования я обнаружил, что люди используют совершенно разные правила. Не имеет значения, если бы только несколько человек использовали разные правила, но почти везде я вижу, как эти разные практики используются.

Так что я просто хотел узнать, в чем причина вышеупомянутых стандартов и почему используются некоторые из этих других стандартов: (они неправильные / старые стандарты?)

1. Большинство методов, которые я видел, начинаются с заглавной буквы, а не со строчной буквы - Практически любой из методов Microsoft, которые я использовал из их импортированных пространств имен. Это, наверное, самый распространенный из тех, что я видел, но я не понимаю

2. Многие люди используют _ для переменных класса .

3. Я видел заглавные буквы по переменным т.е. string MyString;

Я знаю, что я тоже скучал по нескольким, если вы можете придумать что-нибудь, что вы могли бы добавить, и дать объяснение этому, было бы полезно. Я знаю, что каждый разрабатывает свои собственные стили кодирования, но у многих из этих методов есть свои причины, и я бы предпочел придерживаться того, что имеет смысл.

Спасибо,
Matt

Answer 1

Нет веской причины выбирать один стиль кодирования, а не другой.

Самое главное - согласовать стиль кодирования с людьми, с которыми вы работаете . И чтобы помочь вам договориться о стиле кодирования, ваш профессор сказал вам стиль кодирования.

В большинстве случаев это просто точка зрения. Так что просто следуйте стилю кодирования вашего профессора, если вам нужно писать в университете ...

Answer 2

стандарты произвольны, например, по какой стороне дороги двигаться; просто делай так, как тебе говорят; -)

Answer 3

Большинство людей говорят о соглашении об именах стиль , но при приближении к соглашениям об именах следует учитывать и другие вещи, например то, что вы на самом деле называете подпрограммой.

Обычные имена (методы, функции и процедуры) обычно должны иметь форму сильного глагола + объекта, независимо от того, как вы его отформатируете. Например:

paginateResponse()

или

empty_input_buffer()

как (соответственно) против

dealWithResponse()

или

process_input_buffer()

И "dealWith", и "процесс" являются глаголами, но они неоднозначны и заставляют других программистов, работающих с вашим кодом в будущем, обращаться к действительному определению рутины, чтобы определить, что он действительно делает.

«Сильные» глаголы, с другой стороны, как показано в первых двух примерах, намного более мощны по своей описательной силе и действительно определяют, что делает рутина.

Это облегчает чтение вашего кода, поскольку оно самодокументируется, а приводит к более высоким уровням сцепления.

Кроме того, в качестве личного стиля я стараюсь любой ценой избегать использования «моего» в любом имени.

Answer 4

Правила, на которые вы ссылаетесь, довольно универсальны в мире Java.

Вы делаете код Java в университете? Если нет, возможно, они ранее учили Java, а затем переключились на C #, но сохранили соглашения об именах.

Answer 5

В дополнение к основному выводу, что хотя любой конкретный стандарт является по существу произвольным, но важно иметь некоторые согласованные стандарты, я также добавил бы, что некоторые стандарты достаточно повсеместны, чтобы достичь статуса «правильного» пути. делать вещи.

Например, в Java имена классов в профессиональном коде всегда в CamelCase. Я буду всегда утверждать, что ваш код будет компилироваться, если вы нарушаете стандарт, и вы можете иногда находить некоторые проекты с открытым исходным кодом, которые также нарушают соглашение, но я считаю, что большинство людей воспримут это как знак того, что автор не слишком знаком с языком. Большинство ваших руководящих указаний достаточно стандартны (в любом случае для Java). В этом случае радикальное отличие, кроме раздражения вашего профессора, вероятно, будет раздражать совершенно незнакомых людей;)

Мне интересно, что некоторые языки, кажется, приняли эту стандартизацию близко к сердцу и заставляют капитализацию иметь конкретное значение (например, Haskell).

Answer 6

Стили кодирования основаны на личных предпочтениях и в значительной степени на особенностях языка, который вы используете.

Мое личное мнение заключается в том, что более важно соответствовать соглашению, чем выбирать «правильный». Люди могут быть догматичными в том, что они предпочитают стиль, а вещи часто вписываются в религиозную войну.

1. Все классы должны начинаться с заглавной буквы - Это идет рука об руку с именами переменных и помогает избежать путаницы, которая может возникнуть, если у вас и классы, и переменные названы с одинаковыми правилами , Я предпочитаю заглавную букву, потому что я к ней привык, и она соответствует указаниям для моего предпочтительного языка (C #).

2. Все методы должны начинаться со строчной буквы - то же самое происходит, хотя я начинаю свои методы с заглавной буквы (согласно рекомендациям C #).

3. Все переменные должны начинаться со строчной буквы - это, я считаю, зависит от возможностей вашего языка. Часто люди используют префиксные переменные (обычно подчеркивание или символ типа «g»), чтобы указать область действия переменной («g» может означать «глобальный»). Это может помочь избежать путаницы, когда переменные имеют одинаковые имена в разных областях. Мои предпочтения на C #: все переменные начинаются со строчной буквы, и я использую «это». для ссылки на глобальную переменную с тем же именем, где область действия является проблемой (обычно это происходит только в конструкторе класса).

Я не могу позволить 3. пройти без упоминания венгерской нотации (которая используется неправильно и неправильно понимается). У Джоэла есть отличная статья , которая помогла мне лучше понять их.

Answer 7

Стандарты, которые я видел, повторяют то, что содержится в Руководстве по проектированию платформы . В приведенных выше примерах я не вижу, чтобы вы различали видимость (публичная / приватная).

Например:

Методы открытого доступа должны быть PascalCase: public void MyMethod () ... Параметры к методам должны быть camelCase: public void MyMethod (строка myParameter) ...

Поля, которые всегда должны быть закрытыми, должны иметь значение camelCase. Некоторые предпочитают префикс подчеркивания (я делаю), чтобы отличать его от параметров метода.

Лучшая ставка на стандарты заключается в том, чтобы ваша команда заранее согласовала соглашения, когда проект начнется, и вы найдете все гораздо более последовательным.

Answer 8

Я вижу логику за заглавными буквами классов и переменных; это означает, что вы можете делать такие вещи, как

Banana banana; // Makes a new Banana called banana

Я недавно выучил Qt, и они следуют вашим правилам. Я бы никогда не следовал соглашениям Microsoft об именах!

Answer 9

Стандарты помогают с удобочитаемостью и, следовательно, улучшают удобство обслуживания. (потому что, когда вы можете читать код быстрее, проще и точнее, вы можете отлаживать и исправлять его или улучшать его за меньшее время и с меньшими усилиями.)

Они не влияют на надежность или доступность, потому что компьютеру все равно, как называются переменные или как отформатирован код источника.

Если ваш код хорошо организован и читабелен, вы достигли цели, независимо от того, соответствует ли она кому-либо еще или нет "стандарта".

Это, конечно, ничего не говорит о том, как обращаться со средой, в которой "стандарты" стоят в чьем-то списке инструментов оценки разработчиков или метрик управления ...

Answer 10

Я пытаюсь следовать правилам, изложенным в Руководстве по проектированию структуры: условные обозначения, идиомы и шаблоны для многократно используемых библиотек .NET Кшиштофа Квалины и Брэда Абрамса

Руководства в этой книге представлены в четырех основных формах: делай, обдумывай, избегай и не делай. Эти директивы помогают сосредоточить внимание на методах, которые всегда следует использовать, на тех, которые обычно следует использовать, на тех, которые следует использовать редко, и на тех, которые никогда не следует использовать. Каждое руководство включает в себя обсуждение его применимости, и большинство из них содержит пример кода, который поможет осветить диалог.

Кроме того, вы можете использовать FxCop для проверки соответствия этим правилам.