website/blog/coding_style_for_c.html

133 lines
6.1 KiB
HTML

<!DOCTYPE html>
<html lang="en" data-view="home" class="no-js">
<head>
<meta name="viewport" content="width=device-width, minimum-scale=1.0, initial-scale=1.0, maximum-scale=1.0, user-scalable=0">
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="black" />
<meta name="google" content="notranslate" />
<meta http-equiv="x-ua-compatible" content="ie=edge">
<meta charset="utf-8">
<meta name="description" content="">
<meta name="author" content="Löwenware.s.r.o">
<title>Coding Style for C - Löwenware</title>
<link href="/static/style.css" rel="stylesheet" />
<script type="text/javascript">document.documentElement.className='';</script>
</head>
<body>
<div class="main-wrapper">
<div class="overlay">
<svg class="logo"><use xlink:href="/static/sprite.svg#logo"/></svg>
<a href="javascript:;" id="menu__switch" class="menu__switch" title="Switch menu">
<svg class="icon svg-menu-icon" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 24 24">
<g class="svg-menu-group">
<path class="svg-menu-lines" d="m0 4v2h24v-2zm0 7v2h24v-2zm0 7v2h24v-2z"/>
<path class="svg-menu-cross" d="m4.22 2.81-1.42 1.42 7.78 7.78-7.78 7.78 1.42 1.42 7.78-7.78 7.78 7.78 1.42-1.42-7.78-7.78 7.78-7.78-1.42-1.42-7.78 7.78z">
</g>
</svg>
</a>
<div class="logo__text">Löwenware</div>
</div>
<nav id="menu" class="menu">
<ul class="menu__list">
<li><a href="/">Home</a></li>
<li><a href="/about/">About</a></li>
<li><a href="/aisl/">AISL</a></li>
<li><a href="/dotrix/">Dotrix</a></li>
<li><a href="/blog/" class="active">Blog</a></li>
<li><a href="/contact/">Contact</a></li>
</ul>
</nav>
<main class="content text-content">
<h1>The Right Coding Style for C</h1>
<p>Being a C developer means to be facing various style of coding
(or lack of it) quite often. Programmers, communities, corporations and
software foundations may define and follow own rules without (or almost
without) any affect on a resulting application work process and efficiency.
Such freedom and flexibility that C language grants to developers is one of its
greatest adventages and a proof of genius of Dennis Ritchie and
Kenneth Thompson.</p>
<p>But what is the right coding style for C?</p>
<p>Sometime ago during discussion of coding style with one of my customers
I've asked myself this question. Need to say I am quite flexible with code
formatting and ready to change my habbits, especially if there is a reason
behind it. I did some research and found that many people has no idea why to
format code in one or another way. And with all my respect "because Dennis
and Kenneth was doing so" - is not a reason. First of all because it was long
time ago and many things had changed. Another reason "because it is better for
readability" is too subjective. A real reason could be something that affects
some of the important things: product quality, required resources, earnings.
</p>
<p>It is actual even for non-commercial single-maintainer projects, because
program should do its job, your time is a resource and you never know who and
when will be interested in your work in future. Code style and cleanliness in
this case is a somthing that could really affect the price. So it is worth to
follow at least some rules than nothing. Needless to say that for commercial
projects, importance of those things goes higher.</p>
<h2>File Layout</h2>
<p>This is one of the most natural language aspects. Almost all developers
are following such or similar order:</p>
<ul>
<li>Includes of header files</li>
<li>Preprocessor definitions</li>
<li>Types declarations</li>
<li>Functions declarations (if necessary)</li>
<li>Global variables</li>
<li>Function definitions</li>
<li>Definition of main function</li>
</ul>
<p>To get work done you need things to be declared before first use. This
language requirement in the end helps programmer to find necessary definition
or declaration in backward search through file.</p>
<p>Important note here could be done regarding static functions, which
declarations is better to avoid when possible. It helps to keep their
definitions in logical order, preserve file size and simplify developer's life
when function return value or parameters list changes.</p>
</main>
</div>
<div class="footer">
<div class="footer__logo dark-bg">Löwenware</div>
<div class="footer__above">
<!--div class="newsletter">
<form>
<label for="newsletter__email">Subscribe to newsletter</label>
<div class="newsletter__field">
<input type="email" name="email" id="newsletter__email" placeholder="your@email.address" />
<button type="submit" class="submit" name="submit" value="1">Subscribe</button>
</div>
</form>
</div-->
<div class="footer__social">
<a href="/goto/github" title="Go to GitHub"><svg class="icon"><use xlink:href="/static/sprite.svg#github"/></svg></a>
<a href="/goto/gitter" title="Go to Gitter chat"><svg class="icon"><use xlink:href="/static/sprite.svg#gitter"/></svg></a>
<a href="/goto/youtube" title="Go to YouTube channel"><svg class="icon"><use xlink:href="/static/sprite.svg#youtube"/></svg></a>
<a href="/goto/instagram" title="Go to Instagram"><svg class="icon"><use xlink:href="/static/sprite.svg#instagram"/></svg></a>
<a href="/goto/medium" title="Go to Medium page"><svg class="icon"><use xlink:href="/static/sprite.svg#medium"/></svg></a>
<a href="/goto/linkedin" title="Go to LinkedIn profile"><svg class="icon"><use xlink:href="/static/sprite.svg#linkedin"/></svg></a>
</div>
</div>
<div class="footer__below dark-bg">
<div class="footer__credentials">
<div class="copyright">&copy; 2017 - 2019 by Löwenware s.r.o.</div>
<ul class="legal">
<li class="legal__node legal__first"><a href="/privacy-statement.html">Privacy statement</a></li>
<li class="legal__node legal__marker"><a href="/terms-of-use.html">Terms of use</a></li>
</ul>
<div style="clear:left;"></div>
</div>
</div>
</div>
<script async type="text/javascript" src="/static/main.js"></script>
</body>
</html>