coding style.shtml (2652B)
- <!DOCTYPE html>
- <html xmlns="http://www.w3.org/1999/xhtml">
- <head>
- <!--#include file="/templates/head.shtml" -->
- <title>Coding Style — lanodan’s cyber-home</title>
- </head>
- <body>
- <!--#include file="/templates/en/nav.shtml" -->
- <main>
- <h1>Coding Style</h1>
- <p>Done from scratch to note choices done so far instead of copying and modifying after it. This just denotes my preferred coding style but the most important is for a project’s code to be consistent.</p>
- <p>And this applies to all programming languages that I use, even if I’ll use C vocabulary when applicable, implementation of it is done in <a href="/git/dotfiles/file/.clang-format.html">my <code>.clang-format</code> dot-file</a>.</p>
- <h2>Recommended Reading</h2>
- <p>The following contain good information, some of which is repeated below, some of which is contradicted below.</p>
- <ul>
- <li><a href="http://doc.cat-v.org/bell_labs/pikestyle">http://doc.cat-v.org/bell_labs/pikestyle</a></li>
- <li><a href="https://www.kernel.org/doc/Documentation/CodingStyle">https://www.kernel.org/doc/Documentation/CodingStyle</a></li>
- <li><a href="http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man9/style.9?query=style&sec=9">http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man9/style.9?query=style&sec=9</a></li>
- </ul>
- <h2>Choices</h2>
- <ul>
- <li>Tabs for indentation; space for alignment</li>
- <li>C braces break style: Allman when it’s for grouping (ie. C if-else blocks), K&R when the braces are mandatory (ie. C function definition)</li>
- <li>When using <code>includes</code> or similar, have them sorted (so there is deduplication) and grouped at the start of the file</li>
- <li>Line-lenght:<ul>
- <li>Code: 80 soft-limit, 100 hard-limit</li>
- <li>Text: 80 hard-limit, expect when non-breakable (like URLs)</li>
- </ul></li>
- <li>Compacting: do it if it fits the soft-limit</li>
- <li>main function is defined at the end of the file and functions are grouped by topic, preferably by reversed-order of execution (scripting languages habit).</li>
- <li>Functions to be used outside of their defining file should be put in a header. Make them private otherwise. This allows a clean and well-documented API.</li>
- <li>Documentation is mandatory for the API and must be reachable to where they are used. (ie. external for commands/networking, internal for functions)</li>
- <li>Design with extensibility in mind (so avoid booleans, test against sucess rather than error, structs are friends, …)</li>
- </ul>
- </main>
- <!--#include file="/templates/en/footer.shtml" -->
- </body>
- </html>