logo

blog

My website can't be that messy, right? git clone https://hacktivis.me/git/blog.git

coding style.shtml (2652B)


  1. <!DOCTYPE html>
  2. <html xmlns="http://www.w3.org/1999/xhtml">
  3. <head>
  4. <!--#include file="/templates/head.shtml" -->
  5. <title>Coding Style — lanodan’s cyber-home</title>
  6. </head>
  7. <body>
  8. <!--#include file="/templates/en/nav.shtml" -->
  9. <main>
  10. <h1>Coding Style</h1>
  11. <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>
  12. <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>
  13. <h2>Recommended Reading</h2>
  14. <p>The following contain good information, some of which is repeated below, some of which is contradicted below.</p>
  15. <ul>
  16. <li><a href="http://doc.cat-v.org/bell_labs/pikestyle">http://doc.cat-v.org/bell_labs/pikestyle</a></li>
  17. <li><a href="https://www.kernel.org/doc/Documentation/CodingStyle">https://www.kernel.org/doc/Documentation/CodingStyle</a></li>
  18. <li><a href="http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man9/style.9?query=style&amp;sec=9">http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man9/style.9?query=style&amp;sec=9</a></li>
  19. </ul>
  20. <h2>Choices</h2>
  21. <ul>
  22. <li>Tabs for indentation; space for alignment</li>
  23. <li>C braces break style: Allman when it’s for grouping (ie. C if-else blocks), K&amp;R when the braces are mandatory (ie. C function definition)</li>
  24. <li>When using <code>includes</code> or similar, have them sorted (so there is deduplication) and grouped at the start of the file</li>
  25. <li>Line-lenght:<ul>
  26. <li>Code: 80 soft-limit, 100 hard-limit</li>
  27. <li>Text: 80 hard-limit, expect when non-breakable (like URLs)</li>
  28. </ul></li>
  29. <li>Compacting: do it if it fits the soft-limit</li>
  30. <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>
  31. <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>
  32. <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>
  33. <li>Design with extensibility in mind (so avoid booleans, test against sucess rather than error, structs are friends, …)</li>
  34. </ul>
  35. </main>
  36. <!--#include file="/templates/en/footer.shtml" -->
  37. </body>
  38. </html>