Каковы предпочтительные соглашения в именовании атрибутов, методов и классов на разных языках?

Question

Согласны ли названия в разных языках? Если нет, в чем различия?

Answer 1

У каждого языка свой стиль. Хотя бы один. Каждый проект принимает определенный стиль. По крайней мере, они должны. Иногда это может отличаться от канонического стиля, используемого вашим языком - возможно, на основе предпочтений лидеров разработки.

Какой стиль использовать?

Если ваш язык поставляется с хорошей стандартной библиотекой, попробуйте принять соглашения в этой библиотеке.

Если на вашем языке есть каноническая книга (язык программирования C, The Camel Book, Ruby для программирования и т. Д.), Используйте его.

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

Если вы используете несколько языков, не забывайте сохранять гибкость и настраивайте предпочитаемый стиль кодирования в соответствии с языком, который вы используете - при кодировании в Python используйте другой стиль для кодирования в C # и т. Д.

Answer 2

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

lowercase, lowercase_with_underscores * * 1004

Обычно используется для локальных переменных и имен функций (типичный синтаксис 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 для экспортируемых.

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

Кстати: я забыл специально упомянуть венгерские обозначения.

Answer 3

Я думаю, что большинство соглашений об именах будут отличаться, но разработчик, например, я называю переменными, например: mulitwordVarName, однако некоторые разработчики, с которыми я работал, использовали что-то вроде mulitword_var_name или multiwordvarname или aj5g54ag или ... Я думаю, что это действительно зависит на ваше усмотрение.

Answer 4

G'day,

Одна из лучших рекомендаций, которые я могу дать, - прочитать соответствующий раздел (ы) Стив Макконнелла «Полный код» ( Amazon Link ). У него отличная дискуссия о технике именования.

НТН

ура

Rob

Answer 5

Конечно, есть некоторые общие рекомендации, но есть и различия из-за различий в синтаксисе \ дизайне языка.

Для .NET (C #, VB и т. Д.) Я бы порекомендовал следующий ресурс:

• Руководство по проектированию рамок - полная книга по кодированию .NET руководящие принципы, включая наименование конвенции
• Правила именования - рекомендации от Microsoft
• Общие соглашения об именах - другой набор руководств по MS (C #, C ++, VB)

Answer 6

Несколько лет назад мудрый старый программист научил меня злу Венгерской нотации , это была настоящая устаревшая система, Microsoft применила ее в Windows SDK, а затем и в MFC. Он был разработан на свободных типизированных языках, таких как C, а не на языках со строгой типизацией, таких как C ++. В то время я программировал Windows 3.0 с использованием Borland Turbo Pascal 1.0 для Windows, который впоследствии стал Delphi.

Во всяком случае, длинная история в то время, когда команда, над которой я работал, разработала наши собственные очень простые стандарты, применимые почти ко всем языкам, на основе простых префиксов -

• a - аргумент
• л - местный
• м - участник
• г - глобальный

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

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