Программирование best practices и заметки

  • Страуструп “язык программирования c++” считается очень сильной книгой для программистов, которую мало кто может полностью прочитать и понять
  • Идеология PHP от создателя Rasmus Lerdord:
    • лучше иметь плохо работающий в каких то условиях функционал/библиотеку, но который позволяет решить задачи, чем не иметь функционала вообще. Если вы спорите без предложения альтернативной реализации (просто ноете) – вы скорей всего проиграете спор. 
    • я изначально не интересовался программированием – для меня это было средство решения моих задач и программирование было дотошным/скучным. Я старался минимизировать время, которое посвещаю программированию, отсюда появился PHP – его первая версия позволяла мне очень быстро реализовывать проекты клиентам)))) уже потом люди начали интересоваться и привносить свою лепту и я поделился своим проектом – я продавал услуги решения проблем, не инструмент (мой “hammer”). И люди сдавали мне баги, а я их фиксил у клиентов, которые удивлялись моей продуктивности)) Это был 1994, до того как термин open source еще появился. В 1997 я передал права на CVS репозиторий, чтобы любой мог вносить свою лепту в язык и считать его своим (это легко и сейчас, таких аккаунтов более 1000, где-то половина из которых что-то коммитила за последний год). Я старался сделать максимально простым как сам язык, так и возможность его совершенствовать – я лучше помогу новому контрибьютору и укажу на его ошибки, чтобы он стал более продуктивен, чем буду орать на него и отпугну его от проекта.

             

  • Не нужно учить синтаксис, будь то программирование или работа с устройствами. Намного важнее понимать технологии и принципы. Синтаксис на практике натаскается или за’tab’ится (в IDE/CLI).
  • Нет самых лучших языков во всем, так же как и самых худших. Нужно рассматривать язык как инструмент для достижения цели, какие то языки могут решать задачу быстрее/качественнее/надежнее. Знание одного языка существенно облегчает изучение другого (SRE Google).
You should think about any given programming language as being just one of the potential tools in the IT support specialist toolbox. From traditionally platform specific scripting languages like PowerShell for Windows and Bash for Linux, to more general purpose scripting languages, similar to Ruby, like Python and Pearl. There are many options available to the IT support specialist who is interested in automation. If you want, there's also a whole world of more traditionally compiled languages like C, C++, Java, and Go to Explorer. One nice feature of learning the basics of programming in one language is that the concepts you learn can generally be applied to other languages. This transferability means that becoming familiar with a language like Ruby will help you pick up new languages in the future, because you'll be able to spot similarities between them and understand their differences.
  • Документация, исправление багов и работа с community зачастую важнее самого кода – создатель JQuery пишет, что это была единственная среди конкурентов библиотека с документацией (причем актуальной и на весь функционал) и во многом из-за этого она выстрелила.
  • Крупные релизы ПО обычно выходят раз в месяц/два. Реже раз в неделю-две.
  • Высшая математика и алгоритмы редко нужны в программировании. Важнее знать существующие инструменты/библиотеки/умение писать. Сложной математики не много в бизнес задачах.
  • Митапы по IT (coding, devops, bigdata, AI, etc) круты тем, что инфа с них хорошо усваивается и зачастую уникальна. 
  • На stackoverflow для популярных языков есть почти все. Поэтому есть термин stackoverflow coding.
  • Классы – спорно.
    • Есть мнение, что классы следует использовать уже при 100-300 строках кода.
    • Но есть и оппоненты этому мнению с справедливыми аргументами, которые говорят на основе практики, что создавать классы без большой reusability и продуманной архитектуры/структуры является, зачастую, вредным мероприятием. Это не редко усложнение структуры кода, кроме того, многие отказываются от классов ООП (напр. сделанных в C++ в пользу “плоского” C) из-за проблем с производительностью. В классах, при их использовании, наследование следует исключать или избегать – классы общаться между собой должны.
  • Текущий фронтент сложен. После базого курса по js bootstrap (хорошая тема для backend в том числе) все намного сложнее (dom model, flow, rendering и прочее).
  • Nested conditions (напр. вложенные if) лучше максимально избегать т.к. их сложно читать и менять. Лучше их заменять, например, логическими операциями.
Although the indentation of the statements makes the structure apparent, nested conditionals become difficult to read very quickly. In general, it is a good idea to avoid them when you can. Logical operators often provide a way to simplify nested conditional statements.
  • Есть такая общая концепция что explicit лучше чем implicit, но в контексте завершения каждого кода exit или в результате метода выдавать return (в случае с Ruby не обязательно) – это не тот кейс. 
You will notice that there was no need to have quit() at the end of the Python program in the file. When Python is reading your source code from a file, it knows to stop when it reaches the end of the file.
Whitespace errors can be tricky because spaces and tabs are invisible and we are used to ignoring them.
  • Стараться не повторять код, а использовать функции
  • Стараться делить большой/сложный код на отдельные простые функции
  • Даже если язык case-sensitive (переменная Var != var), не стоит это использовать
  • Даже если в языке не задано ограничение по неймингу переменных/функций/классов, стоит использовать стандарты
  • Даже если язык позволяет назвать одинаково переменную и функцию/метод, не стоит это использовать

 

Стилистика

В разных ЯП может различаться, в среднем (pep8 python):

  • Переменные с малой буквы, не с большой, в качестве разделителя между словами подчеркивание
  • Identation важно, особенно в python (4 пробела, не табы) – там без них код просто не заработает
  • После блока кода хорошо оставлять пустую строку, для улучшения читаемости кода
A blank line at the end of a block of statements is not necessary when writing and executing a script, but it may improve readability of your code.
https://pypi.org/project/pep8-naming/
code    sample message
N801   class names should use CapWords convention
N802   function name should be lowercase
N803   argument name should be lowercase
N804   first argument of a classmethod should be named ‘cls’
N805   first argument of a method should be named ‘self’
N806   variable in function should be lowercase

 

 

Комменты

  • Комментировать в целом хорошо, но избыточное комментирование, как и полное его отсутствие, тоже порок, потому что отвлекает
  • Большую часть комментариев можно избежать если правильно, по смыслу ( “mnemonic variable names”), называть переменные (не слишком длинно)
Good variable names can reduce the need for comments, but long names can make complex expressions hard to read, so there is a trade-off.
We often give variables mnemonic names to help us remember what is stored in the variable.
  • Однозначно комментируются неочевидные (со стороны) вещи
Comments are most useful when they document non-obvious features of the code.

 

Этапы разработки ПО

Этапы разработки:

  • анализ потребностей, возможностей реализации
  • алгоритмизация
  • программирование
  • тестирование
Правильное тестирование: dev -> test -> pre prod -> prod
SAP: D/q/p - development/quality/production servers
  • написание документации
  • написание инструкций по работе

 

short-circuiting evaluation – это когда при анализе логического выражения интерпретатор (Python, Ruby, snort content + pcre) заранее знает результат и перестает исполнять его дальше – например:

  • один из элементов TRUE в выражении состоящем из OR
  • один из элементов FALSE в конструкции состоящем из AND
Поэтому сначала зачастую используют наиболее широкие/наименее затратные критерии по оценке (опять же, snort content + pcre), а уже в конце выражения самые узкие/наиболее вычислительно-затратные. 
When Python detects that there is nothing to be gained by evaluating the rest of a logical expression, it stops its evaluation and does not do the computations in the rest of the logical expression. When the evaluation of a logical expression stops because the overall value is already known, it is called short-circuiting the evaluation.
Эта концепция так же используется для защиты от “опасных” операций с проверкой переменных (напр. деление на ноль) в отдельном if: мы создаем перед потенциально опасным логическим выражением guard, который проверяет переменную, которая используется в потенциально опасном логическом выражении. Это называется guardian pattern. 
x >= 2 and (x/y) > 2 % # without guard crashes when devision on zero

The short-circuit behavior leads to a clever technique called the guardian pattern. We can construct the logical expression to strategically place a guard evaluation just before the evaluation that might cause an error as follows:

x >= 2 and y != 0 and (x/y) > 2 % # with guard

Leave a Reply