Являются ли соглашения об именах одинаковыми на разных языках? Если нет, то каковы различия?Каковы предпочтительные соглашения об именах атрибутов, методах и классах на разных языках?
ответ
Как уже говорил другим, вещи рознятся, но вот грубый обзор наиболее часто используемого именования на различных языках:
lowercase, lowercase_with_underscores
:
Обычно используется для локальных переменных и имен функций (типовой C).
UPPERCASE, UPPERCASE_WITH_UNDERSCORES:
Обычно используется для констант и переменных, которые никогда не меняются. Некоторые (более старые) языки, такие как BASIC, также имеют соглашение для использования всех верхних регистров для всех имен переменных.
CamelCase, javaCamelCase:
Обычно используется для имен функций и имен переменных. Некоторые используют его только для функций и объединяют его с нижним регистром или нижним регистром. Когда используется javaCamelCase, он обычно используется как для функций, так и для переменных.
Этот синтаксис также довольно распространен для внешних API, так как это делают Win32 и Java API. (Даже если библиотека использует другое соглашение внутренне они, как правило экспорт с (Java) CamelCase синтаксисом для имен функций.)
prefix_CamelCase, prefix_lowercase, prefix_lowercase_with_underscores:
Обычно используются в языках, которые не поддерживают пространство имен (т.е. C). Префикс обычно обозначает библиотеку или модуль, к которым принадлежит функция или переменная. Обычно зарезервированы для глобальных переменных и глобальных функций. Префикс также может быть в UPPERCASE. В некоторых соглашениях используется строчный префикс для внутренних функций и переменных и префикс UPPERCASE для экспортированных.
Есть, конечно, много других способов назвать вещи, но большинство конвенций основаны на одном из упомянутых выше или на их разнообразии.
BTW: Я специально упомянул венгерскую нотацию.
Конечно, есть некоторые общие рекомендации, но есть различия в различиях в синтаксисе \ дизайне языка.
для .NET (C#, VB, и т.д.) я бы рекомендовал следующий ресурс:
- Framework Design Guidelines - окончательной книгу на .NET кодирования руководящих принципов, включая наименование конвенции
- Naming Guidelines - директивы от Microsoft
- General Naming Conventions - другой набор руководящих принципов MS (C#, C++, VB)
Каждый язык имеет определенный стиль. Хотя бы один. Каждый проект принимает определенный стиль. По крайней мере, они должны. Иногда это может быть другим стилем для канонического стиля, который использует ваш язык - вероятно, на основе предпочтений лидера разработчиков.
Какой стиль использовать?
Если ваш язык поставляется с хорошей стандартной библиотекой, попробуйте принять соглашения в этой библиотеке.
Если на вашем языке есть каноническая книга (язык программирования C, книга верблюдов, программирование Ruby и т. Д.), Используйте это.
Иногда разработчики языка (C#, Java приходят на ум) на самом деле пишут ряд руководств. Используйте их, особенно если сообщество принимает их тоже.
Если вы используете несколько языков, не забудьте оставаться гибким и настроить предпочтительный стиль кодирования на языке, который вы используете - при кодировании в Python использовать другой стиль для кодирования в C# и т.д.
G'day,
Одна из лучших рекомендаций, которые я могу сделать, это прочитать соответствующие разделы (коды) Стива Макконнелла (Amazon Link). Он отлично обсуждает методы именования.
HTH
веселит,
Роб
Я думаю, что большинство именования будет меняться, но разработчик, например, я называю переменные как: однако mulitwordVarName, некоторые из разработчика я работал с использовал что-то вроде mulitword_var_name или multiwordvarname или aj5g54ag или ... Я думаю, это действительно зависит от ваших предпочтений.
Несколько лет назад мудрый старый программист научил меня злу Hungarian notation, это была настоящая унаследованная система, Microsoft применила ее в Windows SDK, а затем в MFC. Он был разработан вокруг свободных типизированных языков, таких как C, а не для сильных типизированных языков, таких как C++. В то время я программировал Windows 3.0 с использованием Turbo Pascal 1.0 от Borland для Windows, который позже стал Delphi.
Во всяком случае Короче в это время команда, которую я работал на развитых наших собственных стандартов, очень простых и применимых почти на всех языках, на основе простых префиксов -
- а - аргумент
- л - местный
- м - член
- г - глобальная
акцент здесь делается на сферу, полагаться на компиляции r для проверки типа, все, о чем вам нужно заботиться, это область действия, в которой хранятся данные. Это имеет много преимуществ по сравнению с неприятными старыми венгерскими обозначениями, поскольку если вы меняете тип чего-либо посредством рефакторинга, вам не нужно искать и заменять все его экземпляры.
Почти 16 лет спустя я все еще поощрять использование этой практики, и нашел, что это применимо практически к любому языку я выработал в.
ThisIsPascalCase, thisIsCamelCase. никогда не слышал о javaCamelCase – 2008-10-30 09:18:10