Существует __debug__
, который является специальным значением, которое действительно предварительно обрабатывает компилятор.
if __debug__:
print "If this prints, you're not running python -O."
else:
print "If this prints, you are running python -O!"
__debug__
будет заменен постоянным 0 или 1 компилятором, и оптимизатор удалит любой if 0:
строки, прежде чем Ваш источник будет интерпретирован.
Самый простой способ установить стандарты кодирования в компании:
Создать документ стандартов и обеспечить его соблюдение.
... люди любят жаловаться на качество кода, но немногие сядут и найдут время, чтобы создать документ стандартов. Это стоит усилий, и пока вы можете обеспечить его соблюдение (проверка кода и т. Д.), Вы обязательно заметите улучшения в своем коде.
У стиля кодирования есть две основные стороны:
Как я это вижу, по вопросам типа №1 нет смысла спорить. Просто установите стандарт в стандарте и обеспечьте его соблюдение (подробнее об этом позже).
Что касается второй проблемы, я, честно говоря, не уверен, должен ли он быть регулирующим. Лично мне нравится добавлять в функции возвращаемые значения для проверки условий ошибок, и я знаю некоторых людей, которым эта практика не нравится. Но, в конце концов, мы обычно прекрасно читаем код друг друга. Подобные вопросы больше связаны с тем, как вы предпочитаете выражать себя. что вам легче написать, и я бы не хотел, чтобы компания разрабатывала правила, доходящие до этого уровня.
Что касается того, как обеспечить соблюдение, документы стандартов хороши, но, по моему опыту, их просто никогда не читают и не соблюдают близко, и вскоре о них забывают. Лучший способ - это иметь какой-то автоматизированный инструмент, который сообщит вам, что вы нарушаете стандарт.
Например, даже будучи совершенно новым программистом на Java, я знал, когда использовать верхний / нижний регистр. идентификаторы просто потому, что Eclipse позволил мне (тихо, ненавязчиво) узнать, что это за стандарт.
Вы всегда можете использовать бесплатные инструменты, такие как StyleCop от Microsoft.
Вы можете отключить или изменить правила, которые вам не нравятся
Как можно обосновать, что что-то прямо над чем-то еще?
Легко: просто не надо. Выберите стиль кодирования, сообщите о нем и обеспечьте его соблюдение.
Большинство компаний используют правила / соглашения стиля кодирования. Это документы, говорящие о том, что вы всегда должны заключать в скобки тело if даже для одной команды, что вы должны делать отступ с помощью табуляции / пробела и т. Д.
Существует множество инструментов для (автоматической) проверки и обеспечения соблюдения кодирования -стиль. (Примером для java-мира является checkstyle, который можно интегрировать в eclipse, а также в решение для непрерывной интеграции, такое как «hudson».)
Я думаю, что здесь важна согласованность. Нет смысла вступать в семантическую дискуссию о том, какой способ лучше другого, если только текущая методология не особенно плоха.
Что важно, так это то, что команда пишет свой код последовательно, чтобы, если кто-то уйдет или попадет под автобус, его / ее коллеги будут знать, что происходит с кодом, когда они будут вынуждены работать с ним.
Во-первых, вам всегда придется применять стили кодирования - согласия никогда не будет.
Вот почему я бы попытался автоматизировать проверку на непротиворечивость. В зависимости от вашего языка вы можете использовать StyleCop (для .Net) или что-то вроде отступа под Linux.
Каждый разработчик может работать со своим собственным стилем кода в своей среде (переформатирование может быть очень простым, в зависимости от вашей среды), но весь зарегистрированный код должен соответствовать стилю компании.
Какой стиль вы выберете? Что ж, часто уже есть популярные стили - в зависимости от языка. Для вашего примера (C #) я бы выбрал стиль Microsoft. Наконец: только руководитель проекта (старший программист) имеет право его настраивать.