developers spend 60% to 70% of their time understanding code
To make any meaningful change in a codebase, developers first need to build a mental model of the code, which can be particularly challenging for large, complex systems. As codebases grow, so does the cognitive load required to understand them, leading to an increased focus on code comprehension as a critical part of the development process. Respondents to the poll note that understanding code is not an isolated activity. Good code understanding makes other tasks, like debugging and refactoring, easier.
LXR Cross Referencer (LXR)is a general-purpose source code indexer and cross-referencer for code comprehension that provides web-based browsing of source code, with links to the definition and usage of any identifier.
Code auditis a comprehensive analysis of source code in a programming project with the intent of discovering bugs, security breaches or violations of programming conventions.
Program comprehensionis a domain of computer science concerned with the ways software engineers maintain existing source code.
Ctagsis a programming tool that generates an index (or tag) file of names found in source and header files of various programming languages to aid code comprehension.
cscopeis a programming tool which works in console mode, text-based interface, that allows computer programmers or software developers to search source code of the programming language C, with some support for C++ and Java.
Code analysis
CodeQLsemantic code analysis engine. CodeQL lets you query code as though it were data.
Static code analysis
Klocworkstatic code analysis and SAST tool for C, C++, C#, Java, JavaScript, Python, and Kotlin identifies software security, quality, and reliability issues helping to enforce compliance with standards.
Naming should really just come out of the thing the method is doing.
Make sure that any given method is either querying for data or commanding that something happen. I.e. "Asking for a value should not change the value".
CQRS also steers you away from a CRUD application, to a task-based one where you focus more on the problem domain in terms of user interactions than just reading and saving data.
Queries
FindXYZ(), GetXYZ() or LoadXYZ - return some data, don't modify any
GetThing() methods cannot return null (they might throw an exception)
FindThing()could return null if the thing wasn't found
Commands
verb-noun - you can think in similar terms to PowerShell's cmdlet naming conventions
Implement commands as a CommandProcessor pattern, where commands are actually objects containing parameters (sometimes only a primary key of an entity). There is the code to look for appropriate "processors" for each command's Type.
If you really need a command to be async, then your command's handler might send a message to an ESB to do so.
I have just separated out queries into its own Project, named Domain.Read. It works with simple Repository pattern with CRUD that returns DTO's - This can be used in any RESTfull API's or internally as a DL and data can requested and transformed as needed. So the reading of data is completely isolated from Write commands and Events with Eventual Consistency.
Правила форматирования должны быть настолько просты, чтобы их могла выполнять программа.
форматирование должно отражать структуру программы
вам не должно требоваться переформатирование при изменении кода
все стили в духе “висячей строки” идут лесом
все табличные форматирования идут лесом
одно из ключевых правил дизайна: размещать связанные вещи рядом, а несвязанные — поодаль
когда я делаю функции такими разреженными, становится сложнее искать границы между ними
профессионалы пишут плотный код
методы не должны быть большими. Что всегда можно выделить еще один метод.
пишите программы, а не текст! В программе у вас есть функции, классы, перечисления и всякие прочие штуки, которые поддерживает ваш язык программирования. Делайте программы из них. Не из пустых строк, комментариев и выравнивания.
если вы начнете работать над структурой программы, а не над текстом и будете стремится довести ее до совершества, произойдет чудо. Окажется, что пустые строки для “отделения смысловых блоков” не нужны. Табличное форматирование не нужно. Комментарии практически не нужны. И ваши функции станут маленькими и плотными
делайте структуру, а не форматирование. Мол, ведь логически эти функции и поле связаны! Вот именно — логически, но не структурно. Если хотите их связать структурно — выделите класс.