Update

programming_style.md

@@ -1,12 +1,12 @@
 # Programming Style/Code Formatting
 
-Probably in majority of cases a [programming language](programming_language.md) lets the programmer choose the aesthetic style in which to write the code (just like a writer may format his text in visually different ways without changing the meaning of it) -- one has a choice in naming variables, indentation and aligning commands, inserting [comments](comment.md) and so on. This gives rise to various styles -- typically a programmer will have his own preferred style, kind of like handwriting, but once he works in a team, some compromise has to be found to which everyone must conform so as to keep the code nice, consistent and [readable](readability.md) by everyone. Some project, e.g. [Linux](linux.md), have evolved quite good, tested and de facto standardized styles, so instead of inventing a custom style (which may not be as easy as it sounds) one may choose to adopt some of the existing styles. While this is more of a surface-level part of programming, it is still quite important and thinking about it may go very deep, it is not to be underestimated.
+[Programming language](programming_language.md) practically always leaves the programmer some [freedom](freedom.md) of styling that can increase (but also decrease) the aesthetic quality and readability of code, just like a writer has freedom in typesetting and choosing different words to express the same idea. As an example we can choose the variable names at our leisure without affecting how the program functions, expressions may include extra unnecessary brackets for better clarity or leave them out for shorter code and brevity, we can (and should) inserting [comments](comment.md), add proper indentation and whitespaces and so on. This gives rise to various programming styles; typically a programmer develops or adopts his own style over time, a "handwriting" of sort, but in a team compromises have to be found and everyone must temporarily conform to the same agreed style so as to preserve consistency and [readability](readability.md), just like artists have to follow the same visual style as part of larger collaborative work. Some project, e.g. [Linux](linux.md), have evolved quite good, tested and de facto standardized styles, so instead of inventing a custom style (which may not be as easy as it sounds) one may adopt some of the existing ones. While formatting and naming may not appear to be so important at first, it mustn't be underestimated as readability issues typically start to show later on as the project grows. On the other hand, however, it's not so difficult to reformat even a relatively large codebase in later stages ([regular expressions](regex.md) and similar tools can help with this very well), it's definitely much easier than reworking the code's architecture.
 
 There exist automatic code formatters, they are often called **code beautifiers**. But not everything can be automated, for example a program will hardly comment your code, or inserting empty spaces to separate logically related parts of a sequential code is also something that human like intelligence is needed for.
 
 ## Recommended LRS C Programming Style/Formatting
 
-Here we propose a programming style and C code formatting you may use in your programs. { It's basically a style I personally adopted and fine-tuned over many years of my programming. ~drummyfish } Remember that nothing is set in stone (except that you mustn't use tabs), the most important thing is usually to be consistent within a single project and to actually think about why you're doing things the way you're doing them. Keeping to the standard set here will gain you advantages such as increased readability for others already familiar with the same style and avoiding running into traps set by short-sighted decisions e.g. regarding identifiers. Try to think from the point of view of a programmer who gets just your source code without any way to communicate with you, make his life as easy as possible. Also suppose he's reading your code on a calculator. The LRS style/formatting rules follow:
+Here we propose a programming style and C code formatting you may use in your programs. { It's basically a style I personally adopted and fine-tuned over many years of my programming. ~drummyfish } Remember that nothing is set in [stone](rock.md) (except that you mustn't use tabs), the most important rule of style is to maintain consistency within a single [project](project.md) and to actually think about why you're doing things the way you're doing them. Sticking to the standard presented here will gain you advantages such as increased readability for others already familiar with the same style and avoiding falls into traps of short-sighted decisions, e.g. regarding identifiers. Try to think from the point of view of a programmer who gets just your source code without any way to communicate with you, make his life as easy as possible. Also assume he's reading your code on a calculator. The LRS style/formatting rules follow:
 
 - **Respect the [LRS](lrs.md) design principles** ([KISS](kiss.md), no [OOP](oop.md), avoid dependencies such as [stdlib](stdlib.md) etc.).
 - **Indentation: use two spaces, NEVER use [tabs](tab.md)**. Why? Tabs are ugly, tricky (look the same as spaces) non-standard behaving characters (behavior is dependent on editor and settings, some processors will silently convert tabs and spaces, copy-paste may do so also etc.), they don't carry over to some platforms (especially paper), some very simple platforms may not even support them; your source will contain spaces either way, no need to insert additional blank character.