Просматривая код сотрудника, я столкнулся с некоторыми орфографическими ошибками в именах функций, а также грамматическими ошибками, такими как «doesUserHasPermission ()» вместо «doUserHavePermission ()» в именах функций и переменных.
Должен ли я указать ему на это или я слишком педантичен, замечая это?
code-reviews
grammar
Рахул
источник
источник
HTTP-Referer
беспокоит меня часто. en.wikipedia.org/wiki/HTTP_referrer#Origin_of_the_term_refererОтветы:
Код с орфографическими и грамматическими ошибками не поддерживается .
Люди не будут помнить плохую грамматику, поэтому они попытаются вызвать функцию так, как она должна была быть написана, и именно так происходят ошибки.
Вы не можете найти что-то в коде, если не знаете, как оно написано.
Большинство людей, которые делают грамматику / орфографию, делают это непоследовательно, поэтому они вводят много ошибок с несоответствующим наименованием. Это особенно проблематично в языках, которые не требуют, чтобы переменные были явно объявлены перед использованием, потому что вы можете ввести новое написание, и ваш код не остановится, чтобы сообщить, что вы облажались.
Исправление этих проблем не педантично, и при этом это не требуется прежде всего мнением других о чьем-то интеллекте, грамотности и т. Д. (Хотя это большой побочный эффект); речь идет о написании качественного, поддерживаемого кода .
источник
Referrer
в оригинальной спецификации HTTP и ударил его по лодыжке. Конечно, это был, вероятно, Бернерс-Ли, и поэтому я чувствовал бы себя виноватым потом ...Да, безусловно. Имя легче запомнить, если оно грамматически правильно. Попытка запомнить имя и грамматические ошибки - это совсем другое.
источник
Не указывайте на них как на недостатки в официальном обзоре кода. Вместо этого отметьте список и поговорите с ним / ней ЧАСТНО о них. Будьте настолько дипломатичны, насколько это возможно, просто «Эй, кое-что я заметил, и я столкнулся с людьми, которые ДЕЙСТВИТЕЛЬНО смотрят свысока на такие вещи, они думают, что программист выглядит небрежным и неряшливым».
Если это код, который клиент увидит, его абсолютно НЕОБХОДИМО исправить. Нравится вам это или нет, это влияет на репутацию вашей компании.
Для примера, который вы привели, я подозреваю, что он начинался как UserHasPermission, и кто-то другой сказал ему, что местная практика - это «UserBlahBlah ()», а не «UserBlahBlah ()», и он просто пропустил изменение грамматики.
источник
Измени это сам.
Надеемся, что вы находитесь в среде, где «владение» кодом не является проблемой. Если у вас есть доступ к проекту в системе контроля версий, просто зайдите и исправьте его самостоятельно. Если вы видите, что конкретный сотрудник постоянно делает один и тот же тип грамматических или орфографических ошибок, вы можете указать на это, но это будет зависеть от ваших отношений, от того, является ли человек носителем английского языка, и от его общей восприимчивости. Но решите ли вы когда-нибудь сделать это или нет, просто идите и исправьте ситуацию. Я делаю это все время, если я вижу опечатку, особенно в сигнатуре метода или публичном свойстве, я просто исправляю это. Иногда я даже не могу удержаться от соблазна исправить опечатку в комментарии, но это только я :)
источник
Я разработчик, чей родной язык не английский, а на самом деле голландский, и я не против, если кто-нибудь укажет мне грамматическую или орфографическую ошибку. Таким образом, я могу постоянно улучшать свой английский. И, конечно, нетрудно исправить все ошибки во всем вашем исходном коде. Простой Perl-скрипт может быть легко написан для цикла по всем файлам в папке. Возможно, даже это можно сделать с помощью sed? Я не знаю.
Поэтому я бы, конечно, указал на грамматические или орфографические ошибки в чужом коде, но только если я абсолютно уверен, правильно ли я говорю.
источник
Полагаю, здесь стоит упомянуть, что заголовок реферера HTTP в протоколе HTTP был ошибочно назван как «реферер» (и мы должны жить с этим / мы научились жить с ним.) :)
источник
Я согласен с другими ответами о том, что код с грамматическими ошибками не поддерживается.
Я также хочу добавить несколько вещей:
источник
Я бы порекомендовал использовать IDE со встроенной проверкой орфографии. IntelliJ Idea прекрасно справляется с Java-программами. Есть много смущающих опечаток, которые он улавливает, не только в именах функций, но, например, в сообщениях об исключениях, которые видит пользователь. Программа, которая производит сообщения, полные опечаток, не внушает особого доверия.
источник
Я делаю это только если
Как примечание: если имена ваших функций достаточно длинные, чтобы иметь грамматику, они, вероятно, слишком длинные. В приведенном примере я бы вызвал функцию userHasPermission и переместил «грамматику» в ваш код, примерно так:
источник
userHavePermission()
это будет неправильно.userHasPermission()
подразумевает, что он возвращает bool из-за грамматики ~ ИЛИ ~, это может означать, что он устанавливает права пользователя. (У офицера есть мост :: у пользователя есть разрешение). Это все еще расплывчато.Это также происходит ОЧЕНЬ МНОГО в моем проекте (будучи заполненным исконно ивритом, русскими или говорящими на арабском языке людьми), но даже на более высоком уровне - часто я вижу код, который использует некоторую неясную терминологию, которая является тем, что словарь произвел как перевод для что имел в виду автор, и это не имеет ничего общего с тем, что они имели в виду ...
Лично, когда это происходит так часто и так много членов команды, которые могли бы написать код еще до того, как я присоединился к проекту, я склонен игнорировать его, потому что это просто не имеет значения.
Однако, если я выполняю какую-то работу в том же файле, что и код или комментарии, которые были написаны давно, и в них есть опечатки, я исправлю их только потому, что это не слишком много работы.
источник
Золотое правило применяется
Я хочу, чтобы другие были спиной к таким вещам, поэтому я помогаю другим. Быть добрым и благосклонным может иметь большое значение в вашу пользу.
источник
Как и в случае со многими другими хорошими практиками программирования, единственный объективный, неполитический и эффективный способ реализации политики правописания в программах - это автоматизировать ее как часть процесса предварительной фиксации. Автоматизация избавит вас от огромного количества жалоб, даже если вам придется написать собственный инструмент для этой цели.
источник
Это небольшая ошибка в коде, но это ошибка. Относитесь к этому как к любой другой ошибке, которую вы найдете. Моя политика заключается в том, чтобы всегда предполагать, что мои коллеги компетентны, и обращаться с ними таким образом, пока они не докажут обратное.
Если это будет единственной ошибкой, я могу просто исправить ее и проверить. Если это шаблон, я могу попросить этого сотрудника просмотреть эти исправления. Дайте им знать, что вы думаете, что они хороший кодер, но это то, что было бы неплохо улучшить. Хотя я не думаю, что когда-нибудь сделаю что-то подобное.
Пока вы не относитесь к этому как к большой проблеме, должно быть легко поставить этого сотрудника в положение, где он может улучшиться, не ставя эго на линию.
источник
userPermission () возможно? -
Последней, с которой я столкнулся, была глобальная проблема, когда результаты поиска не выделялись, потому что имя класса было написано с подсветкой. Очень неясная ошибка, чтобы обнаружить.
источник
Обязательно укажите это, но не тратьте свое время на проверку орфографических ошибок. Используйте инструмент для автоматизации этого на вашем CI. На .net fxCop можно сделать это ...
источник
Это в значительной степени зависит от того, какие ошибки есть, насколько они распространены и насколько они плохие, а также от того, действительно ли это является истинной ошибкой или просто от того, как вы это скажете.
Лично я не могу этого вынести, когда какой-то идиот затягивает 5-минутный просмотр кода на полчаса, потому что он хочет, чтобы все переименовывалось так, как он это делал, и все комментарии переписывались только потому, что ему нравится вставлять весло. Строка регистрации что говорит «Загрузка объектов данных» не нужно менять на «Компонент загрузчика объектов данных теперь будет загружать соответствующие объекты данных из компонента хранения объектов данных».
/ напыщенная речь :)
источник