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

Вот сведения о нем из сети:

Математическая генеалогия:

[genealogy.math.ndsu.nodak.edu]

Профиль на Кворе:

[www.quora.com]

Доклад по математике:

[www.youtube.com]

------------------------------------------------------

[biratkirat.medium.com]

Step 15: Code With Reason ~Yechiel Kimchi

Reason yourself or question your actions, is what everybody should do, be it in life or at work. This applies equally to the coding. We constantly have to push feature in production as needed by the business. As this business decision comes into coding, it may or may not totally be realized into a product. That’s where the reasoning or questioning the implementation comes into place.

How to reason your code?


Be it for a already implemented feature or developing a new one, we should start from the smallest chunk that we can work at a given time. It can be a single statement to a block which is within a method call. We need to reason the existence of each statement playing devil’s advocate with self or with a peer.


Why reason your code?


Reasoning your code leads to us wearing a different hat and seeing from a different perspective. Many a times, just talking about the problem with your peer, may strike you with some Eureka moment, and the solution just is there. Also, we can try to shoulder QA’s responsibility and evaluate the endpoint properties with precondition and post-condition.

This will help us make the code modular into single independent sections, where the bugs can be traced easily or can be made bug free.

Tips on How to reason your code?


Unsurprisingly, most of the tips mentioned can be checked by static code analyzers.



1) Avoid using goto statements, as they make remote sections highly interdependent.

2) Avoid using modifiable global variables, as they make all sections that use them dependent.

3) Each variable should have the smallest possible scope. For example, a local object can be declared right before its first usage.

4) Make objects immutable whenever relevant.

5) Make the code readable by using spacing, both horizontal and vertical. For example, aligning related structures and using an empty line to separate two sections.

6) Make the self-documenting code by choosing descriptive (but relatively short) names for objects, types, functions, etc.

7) Avoid nested section, if you need one, make it a function.

8) Make your functions short and focused on a single task. The old 24-line limit still applies. Although screen size and resolution have changed, nothing has changed in human cognition since the 1960s.
9) Functions should have few parameters (four is a good upper bound). This does not restrict the data communicated to functions: Grouping related parameters into a single object benefits from object invariants and saves reasoning, such as their coherence and consistency.

10) More generally, each unit of code, from a block to a library, should have a narrow interface. Less communication reduces the reasoning required. This means that getters that return internal state are a liability — don’t ask an object for information to work with. Instead, ask the object to do the work with the information it already has. In other words, encapsulation is all — and only — about narrow interfaces.

11) In order to preserve class invariants, usage of setters should be discouraged, as setters tend to allow invariants that govern an object’s state to be broken.




Яндекс-перевод:

Кодируй аргументируя

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

Как аргументировать свой код?


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


Зачем обосновывать свой код?


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

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

Советы о том, как аргументировать свой код?


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



1) Избегайте использования инструкций goto, поскольку они делают удаленные разделы сильно взаимозависимыми.

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

3) Каждая переменная должна иметь минимально возможную область видимости. Например, локальный объект может быть объявлен непосредственно перед его первым использованием.

4) Делайте объекты неизменяемыми, когда это уместно.

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

6) Сделайте самодокументируемый код, выбрав описательные (но относительно короткие) имена для объектов, типов, функций и т.д.

7) Избегайте вложенных разделов, если они вам нужны, сделайте их функцией.

8) Делайте свои функции короткими и сосредоточенными на одной задаче. Старое ограничение в 24 строки все еще применяется. Хотя размер экрана и разрешение изменились, с 1960-х годов в человеческом познании ничего не изменилось.
9) Функции должны иметь несколько параметров (четыре - хорошая верхняя граница). Это не ограничивает данные, передаваемые функциям: группировка связанных параметров в один объект выигрывает от инвариантов объекта и экономит рассуждения, такие как их согласованность и непротиворечивость.

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

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


--------
Пояснение:

В тексте упоминается устойчивое словосочетание «reason your code».

Объяснения можно найти здесь:

[ericnormand.me]

[www.freecodecamp.org]

[accu.org]

Цитата и Яндекс-перевод из последнего текста:

…. reasoning about the code means to comprehend the code, its exact meaning and its limitations, and to be able to properly draw conclusions about its implications – all done in a logical/mathematical way.

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

-------------------------------------------------------------------------------------------------------------------

Отдельные слайды из лекции Йехиэля Кимхи:







Сама лекция:

[ap.hamakor.org.il]


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

1) JOINT STRIKE FIGHTER
AIR VEHICLE
C++ CODING STANDARDS
FOR THE SYSTEM DEVELOPMENT AND DEMONSTRATION PROGRAM
Document Number 2RDU00001 Rev C
December 2005


[www.stroustrup.com]

2) MISRA-C:2004
Guidelines for the use of the C language in critical systems

[caxapa.ru]

3) Linux kernel coding style

[www.kernel.org]

4) Google C++ Style Guide

[google.github.io]

5) GNU Coding Standards
[www.gnu.org]