Liste des Groupes | Revenir à cl c |
On 2024-09-22, David Brown <david.brown@hesbynett.no> wrote:I am happiest with a bracing style that looks good (in my subjective opinion), is easily understandable, is hard for humans to misinterpret, is automated to a large extent by many editors, and is checked by the compiler. I agree that mistakes due to indentation errors should be a thing of the past for people who use decent modern tools. But I'm a seatbelt and airbag kind of programmer, at least when there is no runtime cost - I prefer a method that is inherently hard to get wrong and is /also/ checked and automated by tools.I am not suggesting overuse of braces. I am suggesting /good/ use of them.My super advanced text editor from the future isn't letting me do that:
>
<https://www.synopsys.com/blogs/software-security/understanding-apple-goto-fail-vulnerability-2.html>
>
That's perhaps the most famous example of the havoc caused by omitting
useful braces.
>
Consistency and clarity is important. So is maintainability. Suppose,
for example, you want to add a line "attempts++;" alongside the "ok++;"
line. When the braces are there, the change is exactly that - add the
new line you want. Without the original braces, you are now making
changes to the structural syntax of the code as well when you add in
original braces - or you are making a mistake in the code.
if (failed)
WARN("failed because...");
else
ok++;
attempts++; // automatic deindent
When I add a line after ok++, it deindents it to be at the same
indentation level as the if, before letting me type any content into it.
OK, I lied about the super advanced from the future. It's just Vim.
Also GCC has been able to diagnose misleading indentation for some
years now.
Between those two, there is nothing to worry about; just concentrate on
whether it looks prettier without the braces or with.
Les messages affichés proviennent d'usenet.