Если у моей команды низкий уровень квалификации, должен ли я снизить уровень своего кода? [закрыто]

156

Например, в JS есть общий фрагмент кода для получения значения по умолчанию:

function f(x) {
    x = x || 'default_value';
}

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

Разве я не должен использовать этот трюк тогда? Это делает код менее читаемым для одноранговых узлов, но более читаемым, чем следующие, в соответствии с любым JS-разработчиком:

function f(x) {
    if (!x) {
        x = 'default_value';
    }
}

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

Итак, я должен понизить уровень своего кода, если мои товарищи по команде имеют более низкий уровень, чем я?

Флориан Маргейн
источник
42
Я полагаю, что это сводится к вопросу: «Должны ли вы писать идиоматический код и заставлять людей достигать этого уровня? Или писать неидиоматический код, который объясняет все явно?»
53
Не понижайте уровень мастерства вашего кода! Я многому научился, читая код более продвинутых программистов. Создайте культуру, в которой, если ваши сверстники что-то не понимают, им предлагается задавать вопросы (и учиться). Просто убедитесь, что вы последовательны.
Коста Контос
6
У вас есть отзывы кода? Это было бы отличным местом для них, чтобы задавать вопросы о таком коде.
thegrinner
3
Частью навыков программирования является ясность, принимая во внимание вашу «аудиторию». Эта конкретная идиома, кажется, стоит учить, но, безусловно, будут случаи, когда будет более разумно использовать более прозрачный стиль кодирования.
LarsH
3
Это просто значит, кто думает, что второй пример лучше, чем первый, поскольку то, что делается, кристально ясно? Похоже, что второй пример более читабелен, чем версия с короткими руками, которая является первым примером. Нет ли инструментов, которые автоматически берут созданный человеком код и оптимизируют его для Javascript? Исходя из моего опыта работы с Javascript, фактически выполняемый код не должен быть достаточно простым, насколько это возможно.
Ramhound

Ответы:

135

Хорошо, вот мой взгляд на эту большую и сложную тему.


Плюсы для сохранения вашего стиля кодирования:

  • Подобные вещи x = x || 10идиоматичны в разработке JavaScript и предлагают форму согласованности между вашим кодом и кодом внешних ресурсов, которые вы используете.
  • Более высокий уровень кода часто более выразителен, вы знаете, что получаете, и его легче читать среди высококвалифицированных специалистов.
  • Вы получите больше удовольствия от своей работы. Я лично ценю создание красивого кода. Я думаю, что это приносит мне много удовлетворения в моей работе.
  • Обычно это создает более читаемый стиль. Придерживаться языковых идиоматических выражений может быть очень ценно - они часто являются идиомами по определенной причине.

Минусы для сохранения вашего стиля кодирования:

  • Программистам нижнего уровня будет сложнее не отставать. Часто это люди, которые поддерживают ваш код, и те, кому действительно нужно читать то, что вы пишете.
  • Сопровождающие код, часто код JavaScript приходят с других языков. Ваши программисты могут быть компетентны в Java или C #, но не понимают, как и когда JavaScript отличается точно. Эти точки часто идиоматичны - примером такой конструкции является немедленно вызванное выражение функции (IIFE).

Мое личное мнение

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

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

Самое главное, чтобы оставаться последовательным.

Код команды должен быть написан так, как если бы один человек его кодировал. Вы абсолютно должны согласиться с правилами кодирования. Вы должны соблюдать эти рекомендации. Если в руководящих принципах кодирования указано, что чтение необязательных параметров следует выполнять «менее умным» способом, то так оно и есть.

Бенджамин Грюнбаум
источник
1
Я знаю, что обучение - это постоянная вещь, но действительно ли это задача разработчика - обучать своих коллег? Руководство должно найти работу, наиболее подходящую для них.
CorsiKa
8
@corsiKa Эти разработчики вряд ли изучат все особенности языка через «платное обучение» (т. е. руководство по обучению направит персонал). Я считаю это больным рабочим местом, когда коллеги не учатся друг у друга. Это не так, как ОП должен был бы дать им обучение в классе. Люди могут просто задавать вопросы, когда они застряли, и, как упоминалось в комментарии выше, обзоры кода могут быть полезны для обмена такими знаниями.
MetalMikester
2
Его коллеги-сотрудники должны учиться самостоятельно, на примерах, приведенных ОП (и других). В противном случае они никогда не будут продвигаться дальше своих текущих знаний. ОП не должен занимать часы каждый день, чтобы обучать их лично, но обзоры кода и случайная сессия «коричневой сумки» могут помочь всем (ну, каждый, кто хочет учиться, то есть).
Alroc
1
@corsiKa согласилась с тем, что обзор кода старшего разработчика сам по себе не является адекватным обучением, хотя это может быть хорошим способом определения того, что младшему разработчику следует искать позже.
Дэн Лайонс
2
@ yms Достаточно справедливо, это правильная точка зрения. Я никогда не утверждал, что читаемость является королем. Я категорически против использования нескольких языков, как если бы они были одним и тем же языком. Возражение «заработало» за сотни часов отладки. Хотя я полностью согласен с тем, что удобочитаемость важна, я считаю, что вы не можете обрабатывать коды на нескольких языках одинаково Более того, я думаю, что большая часть «плохой репутации» JavaScript есть именно из-за этого. Люди ожидают, что он будет вести себя как- то на другом языке, но это не так. Я согласен, что удобочитаемость является критически важной. Лучший код всегда более читабелен :)
Бенджамин Грюнбаум
47

Комментарий хорошо

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

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

Вопрос стиля?

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

Как уже говорилось в другом ответе, придерживайтесь его .

Научить человека ловить рыбу ...

Обучение ваших товарищей по команде, вероятно, лучший способ помочь всем участникам. Дайте понять, что если у кого-то возникнет вопрос по коду кода с вашим именем в журнале коммитов или по меткам времени, он может попросить вас об этом. Если у вашей команды есть обзоры кода, это отличная возможность объяснить любой, возможно, запутанный (кхм) хорошо прокомментированный код вашим товарищам по команде. Если в вашей команде нет проверок кода, почему бы и нет? Доберитесь до этого!

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

"Умные" хитрости

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

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

ПОЦЕЛУЙ

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

Corion
источник
10
Проблема в том, что языковые функции рассматриваются как «умные уловки», даже когда я думаю, что они явно не таковы. Вы когда-нибудь видели закрытие? Вы когда-нибудь видели IIFE? Когда-нибудь видели ссылку на функцию, переданную в качестве обратного вызова? Это те языковые особенности, которые знает каждый опытный разработчик JS. Тем не менее, они являются «умными хитростями» для менее опытных разработчиков JS.
Florian Margaine
1
@FlorianMargaine звучит для меня так, как будто вам нужно работать над изменением терминологии, то есть: это не «хитрые уловки», это более продвинутые возможности языка ... 1 подразумевает, что ваш код не совсем понятен / плохая вещь, 2 подразумевает возможность выучить и улучшить «мои» навыки кодирования (как заставить других изменить свою терминологию? Комментировать, задавать вопросы, делиться статьями кода, объясняющими, как эти функции полезны и т. Д.)
Эндрю Бикертон,
3
Если это облегчает вашу головную боль, частью разочарования может быть то, что Javascript как язык ... не имеет смысла. Это имеет смысл для США, людей, размещающих здесь, потому что мы сделали это долгое время. Но независимо от того, как мы заставили язык работать «хорошо», для нейтрального глаза это просто не имеет смысла. На другой ноте; К сожалению, вы можете продемонстрировать ценность найма опытных разработчиков или, предпочтительно, разработчиков на «любом языке» с высокой готовностью изучать новые парадигмы.
Katana314
1
@FlorianMargaine Я тоже работаю в основном на JavaScript, я знаю боль, которую ты чувствуешь. Я подошел к этому, пытаясь обучить товарищей по команде. Крокфордские видео JavaScript ( 1 , 2 ) помогают. Я не думаю, что те вещи, которые вы перечислили, подпадают под «умные» уловки - ваши товарищи по команде должны их изучать - но некоторые вещи, которые вы делаете с этими языковыми функциями, могут быть плохими «умными». Как убедить вашу компанию нанимать опытных разработчиков - это, вероятно, совсем другой вопрос ...
Корион
2
Комментарии не всегда хороши. Я прочитал «Чистый код» некоторое время назад, и некоторые замечания, которые он высказывает по поводу комментариев, превосходны. Если вы чувствуете необходимость писать комментарии для объяснения вашего кода, есть большая вероятность, что код написан плохо. Если код был более выразительным, комментарии излишни. Каждый раз, когда вы собираетесь написать комментарий, остановитесь на мгновение, чтобы подумать, может ли рефакторинг быть лучшим вариантом. Если код является выразительным, объяснение его цели становится ненужным. Кроме того, комментарии могут вводить в заблуждение или просто быть неправильными, если код изменен, но комментарии не обновляются для соответствия.
Папа
34

Кажется, существует огромное отвращение к созданию функции в JS. Это отвращение заставляет людей быть умными и использовать нелепые уловки, просто чтобы держать вещи в одной строке, как это было бы с вызовом функции. Конечно, имя функции в вызове также является дополнительной документацией. Мы не можем прикрепить комментарий к хитрому выражению, потому что тогда это лишит смысла делать это, поэтому мы просто называем его «js idiom», и вдруг это понятно.

Javascript чрезвычайно доступен, большинство людей не едят спецификации на завтрак, как мы. Таким образом, они никогда не поймут, что скрытые предположения и крайние случаи идиомы.

x = x || 'default_value';

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

Когда я смотрю на этот код я вижу « , если это nullили undefined, то установите его значение по умолчанию. Несмотря на то, что будет также косвенно относиться +0, -0, NaN, falseи , ""как не подходящие значения. Я должен помнить , что 3 месяца с этого момента , когда что потребности чтобы изменить. Я, вероятно, забуду это.

Неявное предположение, скорее всего, вызовет ошибку в будущем, и когда ваша кодовая база полна трюков, подобных этому, нет никаких шансов, что вы будете держать их все в своей голове, когда вы думаете о том, на что повлияет модификация. И это для "JS pro", среднестатистический Джо написал бы ошибку, даже если бы для начала требовалось принять ложное значение.

Ваш новый фрагмент имеет более знакомый синтаксис, но все еще имеет вышеуказанную проблему.

Вы можете пойти с:

function f(x) {
    x = valueOrDefault(x, "default_value");
}

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


Теперь, как вы различаете продвинутую языковую функцию, такую ​​как передача функции в качестве аргумента или хитрый трюк || "default"?

Умные трюки всегда работают с некоторыми скрытыми предположениями, которые можно было игнорировать при первоначальном создании кода. Мне никогда не придется модифицировать IIFE на что-то другое, потому что требование изменилось, оно всегда будет там. Может быть, в 2020 году, когда я смогу использовать настоящие модули, но да.

| 0или версия культа грузов, ~~numиспользуемая для настила пола, предполагает положительные и 32-битные целочисленные границы со знаком.

|| "default" предполагает, что все ложные значения такие же, как и отсутствие передачи аргумента вообще.

И так далее.

Esailija
источник
4
Вы концентрируетесь на одном примере. Как насчет использования таких вещей, как IIFE, замыкания, ссылки на функции? Это основной вопрос моего вопроса.
Florian Margaine
1
@FlorianMargaine Вы не думаете, что я рассмотрел это во второй части достаточно хорошо?
Esailija
3
Ну, это ничего не говорит о том, как справиться с ситуацией, когда я просто использую «расширенную языковую функцию», которую товарищи по команде неправильно понимают как «умный трюк».
Флориан Маргэйн
Мне нравится этот ответ +1, я думаю, что он пропускает большую часть вопроса, но он подробно рассказывает о других частях и сценариях, связанных с ним, и объясняет проблемы, возникающие у других разработчиков команды, самостоятельно подбирающих такие концепции без руководства, прочитав ваши код.
Бенджамин Грюнбаум
@FlorianMargaine Вы имеете в виду, как на самом деле справиться с ситуацией на рабочем месте, где вы используете IIFE, и кто-то думает, что это умный трюк? Как я объяснил, поскольку скрытых допущений нет, запоминание типа «переменные не будут глобальными» будет нормально работать в среднем.
Esailija
23

Вы не должны снижать свои навыки программирования, но вам, возможно, придется изменить способ написания кода. Целью, почти прежде всего, является сделать ваш код понятным людям, которые должны его читать и поддерживать.

К сожалению, это может быть чем-то вроде суждения о том, является ли какой-то конкретный стиль «умным» или просто расширенным. Код в вопросе является хорошим примером этого - ваше решение не обязательно лучше, чем другое. Некоторые будут утверждать, что это так, некоторые не согласятся. Поскольку оба решения имеют практически одинаковую производительность во время выполнения (читай: пользователь никогда не узнает разницу), выберите стиль, который наиболее удобен для всей команды.

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

Брайан Оукли
источник
+1. Ни один конкретный пример, приведенный ОП, не является эмпирически лучшим, чем другой, они просто разные.
Росс Паттерсон
очень хороший ответ @ Брайан-Дубли. Приветствия
Энди К
7

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

Общее руководство

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

  1. Если в этом нет особого недостатка, весь код должен быть написан в соответствии с определенным шаблоном или руководством, что позволит разработчикам, которые будут его обслуживать, легко поддерживать его. (Предостережение: следовать плохим шаблонам только потому, что они в настоящее время находятся в базе кода, - ужасная практика.)
  2. Если вы можете найти вескую причину для использования языковой идиомы, которая не легко читается целевой аудиторией, добавьте комментарий. Если вы обнаружите, что вам нужно добавить комментарий к каждой другой строке, вы можете переписать свой код, чтобы сделать его более читаемым для вашей аудитории. Я не считаю ценным быть идиоматичным ради того, чтобы быть идиоматичным.

Конкретный пример

У нас в базе кода большое количество Perl-скриптов. Обычно мы используем Perl только для очень простых операций, и подавляющее большинство кода написано Java-разработчиками, так что его стиль очень похож на Java. У нас есть набор сценариев Perl и структура, написанная «Perl Guru», которая с тех пор покинула нашу фирму. Этот код содержит многие из более неясных идиом Perl, и никто из наших разработчиков, включая меня, не может читать этот Perl-код без особых усилий. Мы часто проклинаем его за это. :)

user606723
источник
5

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

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

DavidR
источник
3

Я бы не назвал ваш пример трюком, а просто идиоматичным. Если вы должны использовать это, зависит IMHO не столько от текущего уровня вашей команды, но если (по крайней мере, некоторые из) ваших товарищей по команде готовы выучить некоторые новые идиомы. Конечно, вы должны обсудить эту тему с ними, а не навязывать им этот стиль. И не стоит просить их каждый день учить 5 новых вещей или «хитростей». Но, честно говоря, если у вас есть только товарищи по команде, которые не хотят изучать что-то новое, даже если это так просто и мало, чем эта идиома, вам следует подумать о переходе в другую команду.

Док Браун
источник
3

Читая этот вопрос и последующие ответы и обсуждения, кажется, есть два момента. Первый: нормально ли использовать расширенные языковые функции? Второе: как я могу сделать это, не выглядя так, будто я «хвастаюсь»?

В первом случае имеет смысл использовать улучшения и расширенные функции. Например: в C # вам не нужно использовать выражения Linq или Lambda, но большинство людей используют это, потому что это делает код более простым и понятным, если вы действительно знаете, что он делает. Сначала это выглядит странно.

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

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

Итак, как вы вносите эти изменения? Постарайтесь обсудить со своими коллегами следующее: знаете ли вы, что эта функция может быть написана таким образом? Обзоры кода и парное программирование могут быть хорошим временем для перекрестного опыления идей. Мне сложно прописать, что делать, потому что я не знаю, в какой среде вы работаете. Я считаю, что некоторые программисты могут быть очень оборонительными и устойчивыми к изменениям. Я снова был виновен в этом. Лучший способ работать с такими программистами - это потратить некоторое время на изучение того, что заставляет их помечать галочки, изучать их фон, а затем сравнивать и сопоставлять ваши стили и опыт с их. Это требует времени, но это хорошо проведенное время. Если возможно, попробуйте и поощряйте их.

Даниэль Холлинрейк
источник
Если вы думаете, что вам будет проще понять, что вы имеете в виду в среде C #, я сомневаюсь, что OP не против - я уверен, что не будет. Этот вопрос не о JavaScript :) Представьте себе, что вы отказываетесь от необязательных параметров или лямбда-выражений в вашем коде, потому что другие разработчики команды не понимают этого - вы бы это сделали? Я думаю, что вы привели некоторые интересные идеи здесь, но если вы перестанете беспокоиться о конкретном языке, вы можете написать его более убедительным образом :)
Бенджамин Грюнбаум
1
Я работаю в основном с C #, так что это был пример, который наиболее легко вспомнить. Вы делаете отличное замечание относительно того, откажусь ли я от полезных языковых функций только потому, что другие не знают о них. Ответом должно быть «нет», но, конечно, хитрость заключается в том, чтобы заставить других увидеть преимущества этого нового пути, который, похоже, является главной проблемой Флориана.
Даниэль Холлинрейк
3

Только не ходите на работу в Royal McBee Computer Corp, потому что, кто скажет, вы не неопытный программист.

конечно, здорово писать краткий и короткий код, и он может быть полезен в среде javascript (ну, пока кто-нибудь не создаст компилятор js для загрузки в браузеры, но это уже другая история).

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

Это единственная важная вещь, которую нужно иметь в виду, поэтому, хотя я бы сказал «да» - иди с этим конкретным оператором, если он работает и понятен, и с твоими «неопытными» разработчиками (хотя, это их унижает, я знаю много Неопытных разработчиков, которые знают все операторы и приемы, поскольку они запомнили различные учебные пособия и ссылки на веб-страницы, они пишут наихудший код, хотя знают каждый маленький трюк ... в этом есть нечто большее, чем совпадение)

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

gbjbaanb
источник
1
Я не знаю ни одного программиста, который бы не вернулся к своему коду (месяц назад!) И сказал: «Кто, черт возьми, это написал». Мы всегда развиваемся в стиле (по крайней мере, мы стараемся). В этом конкретном случае OP пишет код стандартов, а не код WTFish. OP не обсуждает написание «умного» кода или «короче, чтобы быть крутым», это идиоматический JS.
Бенджамин Грюнбаум
2

Ну, для начала это выглядит как базовый JS для меня.

Но в целом - вы не должны использовать умные хаки, если перефразировать: «отладка вдвое сложнее программирования. Если вы пишете код настолько умно, насколько можете, то вы по определению не можете его отладить».

Это не означает, что вы должны избегать кода только потому, что другие его не поймут - вы должны писать код максимально четко и последовательно. Но ваши критерии ясности должны быть «пойму ли я это при первом чтении через год», а не «может ли кто-нибудь это понять».

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

jmoreno
источник
1

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

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

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

JB King
источник
1

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

Я бы предположил, что нам нужны лучшие инструменты для решения этой проблемы. Ничего сложного, заметьте, у нас есть технология, чтобы сделать это более 50 лет. Включите синтаксический анализатор в редакторе, и пусть редактор сохранит исходный текст в виде секспов (да, точно так же, как lisp). Затем источник читается, редактор разбирает его на синтаксический и типографский (вы знаете, пробелы, табуляции, запятые), форму, которую предпочитает пользователь.

Таким образом, вы можете печатать и читать, x = x || 10и другие программисты будут читать его как

if (0 == x) { x = 10;}

В emacs есть все, чтобы сделать это легко.

Паскаль Бургиньон
источник
1
В этом случае мы знаем, кто является зрителем. Они наши сотрудники. Я думаю, что эта фраза обычно используется, когда вы не знаете свою аудиторию.
dcaswell
-1

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

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

jwenting
источник
5
В этом случае я не умный. Я пишу идиоматический код для любого опытного разработчика. Вы понимаете, почему я борюсь сейчас? :)
Florian Margaine
3
Ваш первый абзац точный, но -1, потому что ваш второй абзац находится далеко от цели. Неверно говорить, что этот пример - преднамеренная попытка быть умным. Это на самом деле очень ясно, и что более важно, это идиоматический стиль, с которым согласны многие хорошие разработчики javascript. Это не единственная идиома в javascript для параметров функций по умолчанию, но она является обычной.
Бен Ли