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


14

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

Действительное имя (идентификатор) на одном языке недопустимо на другом. Например...

var new function thisявляются ключевыми словами в JavaScript, но вы можете свободно использовать их в Python. Точно так же list dict defможно использовать в JavaScript без проблем.

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

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

Итак, мой вопрос, какие стратегии вы принимаете ...

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

(Примечание: я говорю только о Python и JavaScript в этом вопросе ... но, пожалуйста, ответьте на вопрос более широко)

-- ОБНОВИТЬ --

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


1
Или просто требуется, чтобы каждое имя переменной начиналось с $. Он работает в PHP, JavaScript и некоторых компиляторах C / C ++ . На полном серьезе, это одна вещь, которую PHP получил право ИМХО.
Джои Адамс

Ответы:


46

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

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

Что сделало меня более продуктивным, так это изучение C и не пытаться использовать синтаксис Pascal на другом языке только потому, что это делало меня более удобным.

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

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


3
Имена, которые имеют смысл - это все, что вам нужно.
JeffO

24

Вы не должны называть вещи "list", "new", "var", "this", так как они не достаточно описательны ни на одном языке.


2
То же самое "функция". Если это не ключевое слово, оно просто не должно быть.
MPelletier

11

Переключение с, скажем, javascript на python уже является переключением контекста. Я не думаю, что это плохо, если имена переменных меняются, особенно если изменения в имени идиоматичны с языком. Можно даже утверждать, что более сложные переключатели контекста могут помочь в этом случае, поскольку это помогает усилить «чувак, вы пишете javascript, а не python».


7

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


5

Большинство зарезервированных слов (на любом языке) довольно общие. Я предпочитаю имена переменных / функций, которые являются более описательными, и это означает, что я почти никогда не сталкиваюсь с этой проблемой. Я должен признать, что был заражен Чарльзом Симони с его оригинальной схемой именования - это было в Xerox в конце 70-х, еще до того, как его назвали венгерской нотацией, - и это также означает, что имена - это нечто большее, чем здравомыслящий человек. будет когда-либо использовать в качестве зарезервированных слов.


5

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

Я могу подумать об одной ситуации, когда это может стать проблемой, когда вы разделяете структуры данных между языками программирования. Например, если у вас есть объект Javascript на стороне клиента, который отражается в объекте Python на стороне сервера, и вы, естественно, хотите, чтобы они имели одинаковые имена для своих членов. В этом случае правило простое: не используйте имена, которые являются зарезервированными словами ни на одном из языков. Вот и все. Запишите это в инструкции, если хотите. Теперь перейдем к более важным задачам.

Кстати, ни список, ни dict не являются зарезервированным словом в Python. Их можно использовать как имена переменных, хотя и довольно паршивые.


3

По моему опыту, решение этой проблемы заключается в том, чтобы иметь широкие соглашения об именах, применимые ко всем языкам. Будь то JavaScript, C # или какой-то другой прикольный язык, способ именования переменных и классов может стать стандартом в кодовой базе, что, как я обычно вижу, решает эту проблему. Соглашения могут быть согласованы на основе консенсуса всех, просто большинство, желающее получить руководство, руководство говорит: «Вот как мы это делаем», или несколько других возможностей, которые я себе представляю.

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


2

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

Если вы планируете перенести код с одного языка на другой, вам может понадобиться список запрещенных имен. Например, мой документ по практике кодирования на C запрещает использование new или class в качестве переменной, поскольку это затрудняет перенос кода на C ++. В этом случае разумно установить правила, облегчающие эту работу, если это станет необходимым,


-2

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


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

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

Венгерская нотация гораздо более запутывает, чем CamelCase ... ;-)
Зик Ханселл

@ Карл: очевидно, предложение ограничено рамками языка. Знаете ли вы, что Java может начинать имена переменных со знака доллара? Я видел код Java, который выглядит как PHP, было очевидно, где предыдущий программист научился программировать!
dotancohen

@dotancohen: Я помню, как смотрел программу на паскале в хобби-журнале много лет назад, когда Паскаль только создавал сцену. Из структуры кода (и того факта, что они использовали глобальные переменные для передачи значений подпрограммам и функциям) было очевидно, что эта программа была одной из лучших базовых программ, которые я когда-либо видел в написании Pascal. ;-)
Зик Ханселл
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.