Стандарты межязыкового кодирования?

Question

Я ищу совет относительно соглашений по кодированию. Основными языками, которые я использую в порядке частоты, являются C #, JavaScript и ActionScript. Все они основаны на ECMA, поэтому синтаксис по большей части взаимозаменяем. Я хотел бы стандартизировать способ написания кода.

Я искал документы по стандартам кодирования и нашел их у разных авторов, в том числе у Microsoft, Adobe, Дуга Крокфорда и у авторов моих книг. Большая часть индивидуальных стандартов идентична. Например, не используйте заглавные буквы, чтобы различать идентификаторы объектов. Хорошо, звучит хорошо.

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

Рекомендации C # имеют тенденцию отличаться друг от друга больше, чем ActionScript и JavaScript друг с другом, что делает это более сложным для меня, так как большее количество языков по сравнению с большим количеством написанного кода. Существует также проблема автоматического форматирования в среде IDE (например, размещение открывающих скобок в функциях в JavaScript и C #).

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

Answer 1

Идиомы, которые имеют смысл в C #, не обязательно будут иметь смысл в Javascript (и наоборот), несмотря на тот факт, что оба используют заостренные скобки и точки с запятой.

Мы используем разные стили кодирования - по большей части стандартный стиль Microsoft для C # и по большей части стандартный стиль jQuery для Javascript. Это может показаться немного странным (случай, когда речь идет о Pascal по сравнению с верблюдом, означает, что у вас есть некоторые объекты C #, имеющие «неправильный» корпус, потому что они в значительной степени просто там, как контейнеры JSON), но я бы не стал пытаться подковать что такое два отдельных языка в одной грамматике.

Answer 2

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

Мы пытались сделать это на одном из моих работодателей с Delphi и C #, и никто не был счастлив.

Answer 3

Мы используем этот документ. Я понимаю, что многие люди используют его. Это своего рода отраслевой стандарт: http://www.idesign.net/idesign/download/IDesign%20CSharp%20Coding%20Standard.zip.

Работает для многих языков, но написано специально для C #.

Answer 4

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

То, что я делал раньше, - это использование одного и того же стандарта для языков в одном и том же стандарте (PHP, Java, Ruby), а затем и некоторых конкретных, если было абсолютно нецелесообразно использовать тот же набор стандартов, а код выглядит по-другому. достаточно, чтобы ваш мозг тоже переключился (например, для скриптов BASH).

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

Answer 5

Мне повезло работать в среде, где мне не нужно соответствовать чьему-либо стандарту

Лично я не следую стандарту Microsoft для C #: вместо этого все имена моих методов и имен свойств используют camelCase (хотя мои типы все еще используют UpperCase). И я украшаю свои данные члена (чтобы их нельзя было спутать с локальными переменными, свойствами и / или параметрами).

Я не понимаю, почему необходимо следовать соглашениям Microsoft об именах; IMO, иногда даже полезно не делать этого: когда я подклассирую тип Microsoft, случай (например, «add») отличает мои методы от методов Microsoft (например, «Add») в базовом базовом классе.

Кроме того, когда я пишу на C ++, я не следую тем же соглашениям об именах, что и авторы стандартных библиотек (которые используют lower_case для своих типов, тогда как я использую UpperCase).

Правда, что другим разработчикам это может / не нравится; например, кто-то прокомментировал некоторый пример кода C #, который я разместил в некотором ответе здесь на SO, чтобы критиковать его не за его содержание, а за соглашение об именах.