Следовать за стилем кодирования исходного автора? Даже если это ужасно / ленивый / заставляет Ваши глаза выйти за край? [закрытый]

Версия Swift + UIAppearance:

    UINavigationBar.appearance().barTintColor = .blackColor()
    UINavigationBar.appearance().barStyle = .Black
12
задан oevna 3 June 2009 в 20:28
поделиться

10 ответов

Follow the original coding style. It is far, far better to be consistent, even if it's not pretty to you.

If you do decide to clean up the coding style, do it separately from any other changes. Don't clutter up source control diff's with style changes. Make one (or several) checkins where the only thing you're doing is changing code style. Do not mix in real changes with meaningless changes, it makes it impossible to locate relevant changes when reviewing source control commits.

40
ответ дан 2 December 2019 в 03:06
поделиться

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

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

5
ответ дан 2 December 2019 в 03:06
поделиться

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

2
ответ дан 2 December 2019 в 03:06
поделиться

При проверке в системе управления версиями вы можете оставить его в покое, поскольку все изменения стиля сделают сравнение с предыдущими версиями невозможным.

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

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

Лично я бы оставил стиль в покое, если вы не вносите существенных изменений.

2
ответ дан 2 December 2019 в 03:06
поделиться

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

Однако я предлагаю выделиться жирным шрифтом и очистить код по своему усмотрению; «Оставьте лагерь чище, чем вы его нашли». Дрянно, но правда;)

Просто убедитесь, что вы готовы защищать свои изменения;)

2
ответ дан 2 December 2019 в 03:06
поделиться

Черт возьми! Что бы вы ни делали, не делайте это хуже , ради всего святого!

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

Я в той же лодке, я должен поддерживать древнюю критически важную для бизнеса систему на основе Access 2, которая представляет собой полную мешанину из стили.

1
ответ дан 2 December 2019 в 03:06
поделиться

Если он даже не поддерживается, почему вы беспокоитесь об этом?

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

0
ответ дан 2 December 2019 в 03:06
поделиться

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

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

0
ответ дан 2 December 2019 в 03:06
поделиться

If you're coding to a company-defined standard (or even just a team-defined standard), and the code that you're working on does not match the standard (or is so old that it doesn't match the current standard), then definitely clean up the code if you're going to be making major changes anyway. (As others have mentioned, do that to the baseline code, and check it in. Then check it out again and make the changes that you have to make to fix bugs, add features, etc.)

0
ответ дан 2 December 2019 в 03:06
поделиться

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

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

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

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

0
ответ дан 2 December 2019 в 03:06
поделиться
Другие вопросы по тегам:

Похожие вопросы: