Вредные советы программистам

Вредные советы программистам

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

Но если вы поставили перед собой цель стать настоящим «говнокодером», забудьте о правилах. Ваш код – только ваш, и плевать на все условности! А чтобы добиться совершенства на выбранном пути, воспользуйтесь нашими советами.

Никогда не соблюдайте соглашения

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

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

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

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

Будьте креативны и делайте, не так как все.

Чем короче код, тем лучше

Вы ведь знаете, что чем меньше строк занимает ваш код, тем он круче? Так было всегда, и только таким образом можно доказать свою крутость матерым программистам. И здесь вам помогут несколько советов:

  • Не используйте перенос строк там, где этого не требует язык. Тем более, если пишите единое выражение. Пишите весь код в одну строку – это обязательно оценят.
  • Незнакомые с английским языком специалисты испытывают неудобства, читая ваши lastName и savedWord. Куда проще использовать однобуквенные переменные: начинать с «a» и по мере продвижения брать следующие буквы латинского алфавита. Если они закончатся — добавляйте цифры.
  • Избегайте пробелов. Количество строк это не уменьшит, но код будет смотреться намного элегантнее.

Счетчики циклов: быть оригинальным просто

Объединим последние два совета в один. Вы наверняка знаете, что в счетчиках всегда используется одна буква: i, j или k. Но что значит «всегда»?

Ваша задача — не просто написать программу, а сделать ее крутой, ведь программирование — это творчество. Поэтому какие-нибудь q, v или z тоже отлично станут на место переменных в счетчиках, особенно тех, которые занимают несколько страниц.

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

Транслитерации и сокращения

Транслитерация и сокращения: простор для фантазии!

Вы же понимаете, что английский язык знают не все. А потому с заботой о коллегах активно применяете транслитерацию. А чтобы коллегам не было скучно, можно применять в одной программе разные написания переменных. Например, в одной части кода объявите переменную «imya», а в другой – «imja». И храните в них разные значения. А нечего расслабляться, программист должен быть внимателен.

А если понадобится третья или четвертая переменная для тех же имен, просто добавьте к этим вариантам цифры. Это сделает ваш код еще оригинальное. Впрочем, можно обойтись обычными сокращениями: nmr или slvr. Краткость — все еще сестра таланта.

Абстракции – это практично

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

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

Не забывайте о том, что у вас есть цифры. И ничто не мешает поставить data1 в первом случае и прибавлять единицу каждый раз, объявляя новую переменную. Это сделает код аккуратнее и понятнее.

Используйте типы переменных как названия

Вы всегда знаете, какой тип данных будет храниться в переменной. Но ведь коллегам будет сложно разобраться, что к чему. Так почему бы и не использовать в качестве имени название нужного типа данных? Представьте, как это будет удобно! Тем более что такое имя достаточно абстрактно и не занимает много места: arr, num, str, obj и так далее.

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

Используйте синонимы

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

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

Второй подход заключается в использовании похожих названий для совершенно разных функций. Например, «renew» может обновлять данные внутри функции, а «update» — выводить их для пользователя. Такого он точно не ждет!

Не слишком раздумывайте над именами

Еще лучше: экономьте силы на именах

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

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

Также не забывайте, что всегда можно использовать сочетание «одна буква +число». Например, идеальной будет работа с переменными «i124» или «D6». Это прекрасная альтернатива креативным абстракциям на случай, если у вас нет времени или настроения.

Не вздумайте писать документацию

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

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

Разработчик достоин использовать ваш код только в том случае, если досконально его изучил.

Функция должна уметь все

Функция должна уметь делать все!

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

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

Программист будет думать, что такая функция всего лишь возвращает число и возьмется искать, где используется результат. А у вас – сюрприз! Вся обработка уже проведена внутри функции.

Можно было бы воспользоваться документацией, однако мы знаем, что ее добавлять нельзя ни в коем случае. Специалист должен всегда быть начеку.

Главное, сделать так, чтобы название функции было довольно однозначным, а ее функциональность отвечала чуть ли не за половину программы.

Возвращайте необычное значение

Воспользуемся примером из раздела выше. Из функции getScore программист ожидает получить либо целочисленное значение, либо – логическое (false/true). Но вы-то его уже обработали, рассказали пользователю, где он не прав и даже спросили, готов ли он пройти проверку снова.

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

Самые важные советы программистам

Кратко о самом важном

Этот раздел для самых-самых крутых, для истинных «говнокодеров», не способным читать длинные тексты:

  • Забудьте об английском языке. Мы доказали действенность однобуквенных переменных и транслитерации. И вообще, английский программисту ни к чему. В Рунете больше чем достаточно работы, а новые языки можно учить тогда, когда выйдет перевод. Это надежнее, и не важно, что вы всегда будете «плестись в хвосте» коллег.
  • Не тратьте время на планирование. Чем раньше вы начнете писать код, тем больше времени будет непосредственно на написание. Планы, алгоритмы – это для студентов, крутой профи может «в голове» все представить и быстро написать.
  • Никогда не занимайтесь тестированием. Если вы написали программу, то она будет работать без багов. Вы же уверенный в себе профессионал!
  • Не трогайте чужой код. Вы можете заразиться плохим стилем, поэтому, получив задание доработать программный продукт, просто сотрите код и напишите все сами.
  • Никогда не удаляйте фрагменты кода. Если есть необходимость обновить старый код, то просто закомментируйте то, что не нужно, и добавьте обновления ниже. А если понадобится снова что-то изменить, повторите действия. Код удалять жалко, тем более, что все равно комментариями вы не пользуетесь по назначению.
  • Забудьте о системах контроля версий. Эти инструменты мешают нам развиваться. Если что-то не получилось — нужно не возвращаться назад, а писать все заново.
  • Не обращайте внимания на ошибки. Все исправится само собой в процессе написания кода. Программа обязательно будет работать. И вообще, тестирование отдельных функций – лишняя трата времени.
  • Усложняйте – это круто. Не стоит писать простыми выражениями то, что можно сделать сложным. Иначе никто не узнает, насколько круто и оригинально вы умеете писать.
  • Не используйте новое. Новое — это хорошо забытое старое, а что-то действительно новое точно будет плохо работать и давать не тот результат, которого хотелось бы.
  • Интегрируйте технологии, даже если они не подходят. Показывайте не только ваши возможности в написании кода, но и знание других технологий. Даже если они найдут применение в одном-единственном месте или вообще не понадобятся… пусть будут… на будущее.
  • Сертификаты можно выбросить в помойку или просто не брать. Главное — это ваш опыт. А то что вас отметили в Google или Microsoft, это ничего не значит. Может, вы им заплатили. В это все равно никто не поверит.


[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]

3 комментария к “Вредные советы программистам”

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх