Как заставить себя следовать именам и другим соглашениям

Question

Я верю, я программирую хорошо, по крайней мере, мой код дает результаты ...

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

Однако, если он не читается, он исчезнет, ​​потому что со временем вы не вспомните, что он делает. Чтобы избежать этого, выполните рефакторинг и документируйте свой код, как только он заработает . Как правило, вы не должны быть удовлетворены своей работой, пока она не будет должным образом документирована. Для каждого написанного вами метода это не должно занимать слишком много времени. Но чем дольше вы будете ждать, тем больше времени потребуется, чтобы выяснить, что должен делать ваш код.

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

-Карлос Нуньес

Answer 7

Запуск чего-то вроде StyleCop (если вы пишете на C #) может помочь в этом. Он не будет предупреждать вас обо всем, но вы можете использовать его, чтобы убедиться, что ваши методы имеют комментарии к документации и т. Д.

Однако, как говорили другие, кодовая дисциплина - это то, что должно исходить изнутри, а не снаружи.

Answer 8

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

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

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