{"id":1592,"date":"2015-08-31T07:48:15","date_gmt":"2015-08-31T05:48:15","guid":{"rendered":"http:\/\/www.blue.pri.ee\/ttu\/?page_id=1592"},"modified":"2026-05-29T16:14:23","modified_gmt":"2026-05-29T14:14:23","slug":"coding-style","status":"publish","type":"page","link":"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/","title":{"rendered":"Coding style"},"content":{"rendered":"<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_85 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<span class=\"ez-toc-title-toggle\"><a href=\"#\" class=\"ez-toc-pull-right ez-toc-btn ez-toc-btn-xs ez-toc-btn-default ez-toc-toggle\" aria-label=\"Toggle Table of Content\"><span class=\"ez-toc-js-icon-con\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/span><\/a><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#Introduction\" >Introduction<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#Line_length\" >Line length<\/a><ul class='ez-toc-list-level-4' ><li class='ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#Splitting_lines\" >Splitting lines<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#Splitting_strings\" >Splitting strings<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#Comments\" >Comments<\/a><ul class='ez-toc-list-level-4' ><li class='ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#A_good_vs_bad_comment\" >A good vs bad comment<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#File_header\" >File\u00a0header<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#Declaring_and_initializing_variables\" >Declaring and initializing variables<\/a><ul class='ez-toc-list-level-4' ><li class='ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#Declaring_pointers\" >Declaring pointers<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#Arithmetic_and_boolean_operations\" >Arithmetic and boolean operations<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#define_preprocessor_directives\" >#define preprocessor directives<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-12\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#Conditionals\" >Conditionals<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-13\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#Switch\" >Switch<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-14\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#Indentation\" >Indentation<\/a><ul class='ez-toc-list-level-4' ><li class='ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-15\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#Indentation_depth\" >Indentation depth<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-16\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#Loops\" >Loops<\/a><ul class='ez-toc-list-level-4' ><li class='ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-17\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#Nested_loops\" >Nested loops<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-18\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#_Functions\" >\u00a0Functions<\/a><ul class='ez-toc-list-level-4' ><li class='ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-19\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#main_function\" >main() function<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-20\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#User-defined_functions\" >User-defined functions<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-21\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#Naming_your_functions\" >Naming your functions<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-22\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#Function_comments\" >Function comments<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-23\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#Function_prototypes\" >Function prototypes<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-24\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#Enumerations\" >Enumerations<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-25\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/#Structures\" >Structures<\/a><\/li><\/ul><\/nav><\/div>\n<h3><span class=\"ez-toc-section\" id=\"Introduction\"><\/span>Introduction<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>The main purpose of a coding style (or coding standard) is to ensure that the work of multiple contributors within a project (or a company) produces code that is uniform in style. That increases the readability of the code and makes it easier for others to update the code if\/when that should become necessary. The styles vary from project to project and company to company so the first step when becoming a contributor\/employee is to familiarize yourself with the coding style that the project\/company uses.<\/p>\n<p>A good coding style may also reduce coding errors, for example it&#8217;s easier to spot a missing brace when braces are always on a separate line. In the end tho the code needs to be both syntactically and semantically correct and style alone doesn&#8217;t guarantee this. During compiling all style elements like indentation, multiple spaces, newlines and comments are removed.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Line_length\"><\/span>Line length<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>A line should not be longer than 80 characters. This comes from historically monitors being able to display 80 characters per line.<\/p>\n<p>Since technology has advanced over time, the line length limit of 80 is strongly recommended (future employer might not be so lenient). Exceeding a by one or two characters will not be frowned upon, but once you reach 90 or more, you need to wrap your lines or restructure your code.<\/p>\n<p>IDEs provide visual clues as to when a line is over length.<\/p>\n<p>Geany: Edit -&gt; Preferences -&gt; Editor -&gt; Display<br \/>\nChoose <strong>Long line marker: Enabled<\/strong> and <strong>Column: 80<\/strong><\/p>\n<h4><span class=\"ez-toc-section\" id=\"Splitting_lines\"><\/span>Splitting lines<span class=\"ez-toc-section-end\"><\/span><\/h4>\n<p>C language doesn&#8217;t care about spaces or tabs. Thus, splitting lines in C doesn&#8217;t require any additional symbols. Splitting lines is partially regulated and partially an art. The goal is to make it readable.<\/p>\n<pre class=\"toolbar:2 nums:false lang:c decode:true\">\/\/ Printing the contents of the structure\r\nprintf(\"%7d %4s %10s %10s %2d.%2d.%4d\\n\", student.id,\r\n    student.field, student.fName, student.lName,\r\n    student.birthday.day, student.birthday.month,\r\n    student.birthday.year);\r\nprintf(\"End of structure\");\r\n\r\n\/\/ Long equations example\r\nx1 = (-linearCoefficient + sqrt((linearCoefficient * linearCoefficient) - \r\n                               (4 * quadraticCoefficient * constant))) \/\r\n                               (2 * quadraticCoefficient);\r\nx2 = (-linearCoefficient - sqrt((linearCoefficient * linearCoefficient) - \r\n                               (4 * quadraticCoefficient * constant))) \/\r\n                               (2 * quadraticCoefficient);<\/pre>\n<ul>\n<li>Line is being split before reaching 80 characters<\/li>\n<li>Split lines are indented by <strong>at least<\/strong> one.<\/li>\n<li>Since splitting is partially a creative undertaking, it may be prudent to indent by more than 1.<\/li>\n<li>It is in good style to split lines before or after operators<\/li>\n<li>Once the statement is finished, the code continues as it was before.<\/li>\n<\/ul>\n<h6><span style=\"color: #ff0000;\">Don&#8217;t do this:<\/span><\/h6>\n<p>The following line is too long and requires horizontal scrolling. It is hard to read and modify.<\/p>\n<pre class=\"theme:github-copy toolbar:2 nums:false nums-toggle:false copy:false scroll:true expand:true lang:c decode:true\">printf(\"%s %s %d - got %.2f of the votes\\n\", (candidates + total)-&gt;candidate, (candidates + total)-&gt;party, (candidates + total)-&gt;votes, ((float)(candidates + total)-&gt;votes \/ (float)votes) * 100);<\/pre>\n<h4><span class=\"ez-toc-section\" id=\"Splitting_strings\"><\/span>Splitting strings<span class=\"ez-toc-section-end\"><\/span><\/h4>\n<p>Strings cannot be split in between the double quotes.<\/p>\n<pre class=\"toolbar:2 nums:false lang:c decode:true\">\/\/ Splitting strings\r\nprintf(\"This is an extremely long sentence that needs to be split up in \"\r\n       \"order to adhere to the line length requirements.\\n\");<\/pre>\n<ul>\n<li>First, finish the strings using double quotes. Then start the string again on the next line.<\/li>\n<li>It&#8217;s recommended to indent to the point where the string begun on the previous line.<\/li>\n<li>Alternatively, you can split up the string in between multiple print statements.<\/li>\n<\/ul>\n<h3><span class=\"ez-toc-section\" id=\"Comments\"><\/span>Comments<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>The purpose of commenting code is to increase readability and manageability of the code. Everything may seem clear when initially writing the code, but when returning to it in a couple of days, weeks, months or even years, it will be very difficult to figure out what was written at the time and why is it written like that. Even worse will be to find and fix mistakes and make changes.<\/p>\n<p>Well commented code isn&#8217;t only important for you, but also your coworkers who you will share the codebase with.<\/p>\n<p>You should mainly comment &#8220;interesting&#8221; parts of the code. Understanding what is interesting comes with experience. Definitely\u00a0<strong>do not<\/strong> comment every line &#8211; this increases unreadability. For starters, aim to have\u00a0<strong>1 comment every 5 lines<\/strong> on average. Once you gain experience, sometimes it will be necessary to comment every line, at other times, you might not see a comment for 10 &#8211; 20 lines straight.<\/p>\n<p>There are several options for writing comments:<\/p>\n<ul>\n<li>Single line comments<\/li>\n<li>Inline comments<\/li>\n<li data-select-like-a-boss=\"1\">Multiline comments (see <a href=\"#style_file_header\">File Prolog<\/a>)<\/li>\n<\/ul>\n<pre class=\"toolbar:2 striped:false marking:false nums:false nums-toggle:false lang:c decode:true\">\/\/ This is a comment on a separate line\r\nif (debug == true)\r\n{\r\n    printf(\"Debugging on\"); \/\/ This is an inline comment\r\n}\r\n<\/pre>\n<ul>\n<li>It is recommended to prefer separate line comments to inline comments for readability<\/li>\n<li>Put a space after the comment symbols.<\/li>\n<li>Comment starts with 2 forward slashes and ends when the line ends.<\/li>\n<li>Prefer short and straight to the point comments.<\/li>\n<li>Adhere to line length limitation.<\/li>\n<\/ul>\n<h4><span class=\"ez-toc-section\" id=\"A_good_vs_bad_comment\"><\/span>A good vs bad comment<span class=\"ez-toc-section-end\"><\/span><\/h4>\n<p>A good comment explains <strong>at least<\/strong> one of the following:<\/p>\n<ul>\n<li><strong>what<\/strong> are you doing<\/li>\n<li><strong>why<\/strong> are you doing it<\/li>\n<\/ul>\n<pre class=\"toolbar:2 nums:false lang:c decode:true\">\/\/ Calculate hypotenuse of a right triangle.\r\nfloat hyp = sqrt((base * base) + (height * height));<\/pre>\n<p><span style=\"color: #ff0000;\"><strong>Don&#8217;t do this!<\/strong><\/span>\u00a0A bad comment explains <strong>how<\/strong> you are doing it.<\/p>\n<pre class=\"toolbar:2 nums:false lang:c decode:true\">\/\/ Add squares of base and height together and take a square root\r\nfloat hyp = sqrt((base * base) + (height * height));<\/pre>\n<p>The comment is bad because it doesn&#8217;t provide anything addition to what can already be read from the code. If there&#8217;s a mistake in the code, you cannot identify it. Given this code to a friend or a colleague, they can not see the discrepancy between what you intended to do and what you actually wrote in code.<\/p>\n<p><a title=\"style_file_header\" name=\"style_file_header\"><\/a><\/p>\n<h3><span class=\"ez-toc-section\" id=\"File_header\"><\/span>File\u00a0header<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>All .c and .h files should have a header that lists the name of the file, author(s) and the purpose of the code in the file. For public projects, an e-mail address or a URL may also be added.<\/p>\n<p>Often the creation creation and last change date (or version number) is also added to the header. In some cases you may also see the changelog of the file, however these days it is more likely to be in the version control software (e.g. Git).<\/p>\n<pre class=\"lang:c decode:true\" data-select-like-a-boss=\"1\">\/**\r\n * File:        singularity.c\r\n * Author:      Risto Heinsar\r\n * Created:     19.08.2014\r\n * Last edit:   27.08.2015\r\n *\r\n * Description: Experimental program to test dividing by\r\n *              zero\r\n *\/\r\n<\/pre>\n<p>Multiline comments are typically between the \/* and *\/ symbols &#8211; everything in between is considered a comment.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Declaring_and_initializing_variables\"><\/span>Declaring and initializing variables<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<pre class=\"toolbar:2 striped:false marking:false nums:false nums-toggle:false lang:c decode:true \">\/\/ Single variable\r\nfloat average;\r\n\r\n\/\/ Declaration and initialization\r\ndouble trackLength = 500.0;\r\n\r\n\/\/ Multiple variable declaration, initialization not allowed\r\nint hours, minutes, seconds;<\/pre>\n<ul>\n<li>Variable names should indicate what they are for (self-explanatory).<\/li>\n<li>Names should follow <span class=\"lang:default highlight:0 decode:true crayon-inline \">lowerCamelCase<\/span>\u00a0 convention: first word is lowercase, every following word starts with uppercase.<\/li>\n<li>It&#8217;s possible to declare several variables of the same type with a single declaration, in that case variables should be separated by comma.<\/li>\n<li>Initialization should be done only when declaring a single variable or on a separate line.<\/li>\n<li><strong>Avoid global variables\u00a0<\/strong>(some exceptions apply),<\/li>\n<li>Variables should be declared near where they are first used.<\/li>\n<\/ul>\n<h6><span style=\"color: #ff0000;\">Do not do this!<\/span><\/h6>\n<pre class=\"theme:github-copy toolbar:2 nums:false nums-toggle:false copy:false lang:c decode:true\">int a, b, c, x, k, l, m, n; \r\nint n = 10, min, i = 0, max, divisor, coef = 9; \r\nint arrcounterforthefirstgrouponseconditerationoflist;<\/pre>\n<ul>\n<li>First line: single letter variable names should be avoided, as their purpose is hard to understand later on and accidentally mixing them up is quite common. A reasonable exception to his would be naming loop counters and commonly understood names (e.g. n &#8211; number of objects)<\/li>\n<li>Second line: It&#8217;s a mix of initialized and uninitialized variables. They should be declared on separate lines, as this is confusing and mistakes are prone to happen.<\/li>\n<li>Third line: Even though the name seems descriptive, it is written in an unreadable manner, as the word separation is not clearly visible. It should also be considered if this long variable names are reasonable.<\/li>\n<\/ul>\n<h4><span class=\"ez-toc-section\" id=\"Declaring_pointers\"><\/span>Declaring pointers<span class=\"ez-toc-section-end\"><\/span><\/h4>\n<p>Declaring pointers mostly uses the same principles as declaring variables. There are a few additional detalis to notice however.<\/p>\n<pre class=\"toolbar:2 striped:false marking:false nums:false nums-toggle:false lang:c decode:true\">\/\/ single pointer\r\nint *pData;\r\n\r\n\/\/ multiple pointers\r\nint *pFirst, *pLast;\r\n<\/pre>\n<ul>\n<li>The symbol * is right before the variable name (no space in between).<\/li>\n<li>Pointers are typically prefixed with a lower case p character to indicate it being a pointer.<\/li>\n<li>Pointers are declared separate from non-pointer variables.<\/li>\n<\/ul>\n<h6><span style=\"color: #ff0000;\"><strong>Do not do this!<\/strong><\/span><\/h6>\n<pre class=\"theme:github-copy toolbar:2 nums:false nums-toggle:false copy:false lang:c decode:true\">int* pData;\r\nint* pList, val;<\/pre>\n<ul>\n<li data-select-like-a-boss=\"1\">Writing the asterisk after the data type gives false assumption that all variables declared on this line will be pointers.<\/li>\n<li data-select-like-a-boss=\"1\">In the second line you may think that <span class=\"lang:default highlight:0 decode:true crayon-inline \">val<\/span>\u00a0 is also a pointer, but instead it will be an integer. Always declare pointers and non-pointers separately.<\/li>\n<\/ul>\n<h3><span class=\"ez-toc-section\" id=\"Arithmetic_and_boolean_operations\"><\/span>Arithmetic and boolean operations<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<pre class=\"toolbar:2 striped:false marking:false nums:false nums-toggle:false lang:c decode:true\">\/\/ Simple binary math operation\r\na = b + c;\r\n\r\n\/\/ Slightly more complicated math operation\r\naverage = (firstResult + secondResult) \/ 2;\r\n\r\n\/\/ Logic operation. Both binary and unary operators.\r\n(((month == 1) || (month == 2)) &amp;&amp; !holiday)\r\n\r\n\/\/ Unary operation (bitwise inversion)\r\na = ~a\r\n\r\n\/\/ Variable decrement\r\nk--<\/pre>\n<ul>\n<li>All operations that take 2 or more arguments (binary operators) should have spaces around the operator.<\/li>\n<li>Unary operators should have no spaces between operator and preceding\/following operand. For example <span class=\"lang:default highlight:0 decode:true crayon-inline \">!holiday<\/span>\u00a0 (NOT holiday), <span class=\"lang:default highlight:0 decode:true crayon-inline \">~a<\/span>\u00a0 (INV a), <span class=\"lang:default highlight:0 decode:true crayon-inline \">k&#8211;<\/span>\u00a0 (decrement k by 1).<\/li>\n<\/ul>\n<h6><span style=\"color: #ff0000;\">Do not do this!<\/span><\/h6>\n<pre class=\"theme:github-copy toolbar:2 nums:false nums-toggle:false copy:false lang:c decode:true\">P=(V2+(C\/d)*1.25)\/tmp+sqrt(x);<\/pre>\n<p>The lack of spaces is causing issues with the readability of this statement. It will be difficult to check if it was written correctly and introduce changes.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"define_preprocessor_directives\"><\/span>#define preprocessor directives<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<pre class=\"toolbar:2 striped:false marking:false nums:false nums-toggle:false lang:c decode:true \">#define DATAPOINTS 10\r\n#define MAX_SIZE 5\r\n#define INPUTFILE \"settings.ini\"<\/pre>\n<ul>\n<li>Defines\u00a0are used to avoid magic numbers in the code, amongst other things<\/li>\n<li>Defines\u00a0are in FULL_UPPERCASE. If the name consists of several words then underscore is used to separate them.<\/li>\n<\/ul>\n<h6 data-select-like-a-boss=\"1\"><span style=\"color: #ff0000;\">Do not do this!<\/span><\/h6>\n<pre class=\"theme:github-copy toolbar:2 nums:false nums-toggle:false copy:false lang:c decode:true \">#define limit 10\r\n#define ARRAYMINVAL 0\r\n<\/pre>\n<ul>\n<li>In the first example, the macro definition may be mistaken to a variable declaration. This may cause confusion later, as you may try to change this value, however cannot.<\/li>\n<li>The second example has bad readability as the word separation isn&#8217;t clearly visible.<\/li>\n<\/ul>\n<h3><span class=\"ez-toc-section\" id=\"Conditionals\"><\/span>Conditionals<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<pre class=\"toolbar:2 striped:false marking:false nums:false nums-toggle:false lang:c decode:true\">if (value &lt; 0)\r\n{\r\n    printf(\"Value is negative!\\n\");\r\n}\r\nelse if (value &gt; 0)\r\n{\r\n    printf(\"Value is positive!\\n\");\r\n}\r\nelse\r\n{\r\n    printf(\"Value is zero!\\n\");\r\n}<\/pre>\n<ul>\n<li>Opening and closing braces should be on separate lines.<\/li>\n<li>The curly brackets must be the same distance from the left edge (e.g. they align underneath each other)<\/li>\n<li>Content of the braces is indented by 1 (4 spaces).<\/li>\n<li>The keyword <span class=\"lang:default highlight:0 decode:true crayon-inline \">else<\/span>\u00a0 is on a separate line. There are no empty lines between the last closing curly bracket and the keyword <span class=\"lang:default highlight:0 decode:true crayon-inline \">else<\/span>\u00a0.<\/li>\n<li>There is a single space between the keyword <span class=\"lang:default highlight:0 decode:true crayon-inline\">if<\/span>\u00a0 and <span class=\"lang:default highlight:0 decode:true crayon-inline\">(<\/span>\u00a0.<\/li>\n<li>Arithmetic, comparison and logical operators are surrounded by spaces. This does not apply to unary operators (~, ^, &amp;, |, !)<\/li>\n<\/ul>\n<h6 data-select-like-a-boss=\"1\"><span style=\"color: #ff0000;\"><strong>Do not do this!<\/strong><\/span><\/h6>\n<pre class=\"toolbar:2 nums:false lang:default decode:true\">if (value == 0)\r\n    {\r\n    printf(\"Value is zero!\\n\");\r\n    }\r\n\r\nelse\r\n    {\r\n    printf(\"Value is non-zero!\\n\");\r\n    }<\/pre>\n<ul>\n<li>Placing of the curly brackets is confusing, regardless of the style you may have.<\/li>\n<li>The empty line before the <span class=\"lang:default highlight:0 decode:true crayon-inline \">else<\/span>\u00a0 keyword makes it not clear that it is connected to the <span class=\"lang:default highlight:0 decode:true crayon-inline \">if<\/span>\u00a0 statement before. It also may tempt to write code statements in between, which would be an error.<\/li>\n<\/ul>\n<h3><span class=\"ez-toc-section\" id=\"Switch\"><\/span>Switch<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<pre class=\"toolbar:2 striped:false marking:false nums:false nums-toggle:false lang:c decode:true\">switch (variable)\r\n{\r\n    case 0:\r\n        \/\/ actions\r\n        break;\r\n    case 1:\r\n        \/\/ actions\r\n        break;\r\n    default:\r\n        \/\/ actions\r\n        break;\r\n}<\/pre>\n<ul>\n<li>There is a space after switch.<\/li>\n<li>There is a space after case.<\/li>\n<li>The contents of switch is between curly brackets and is indented. Curly brackets are on separate lines and they are the same distance from the left (horizontally aligned).<\/li>\n<li>The contents of each case are indented once more.<\/li>\n<li>Don&#8217;t forget break statements.<\/li>\n<\/ul>\n<h3><span class=\"ez-toc-section\" id=\"Indentation\"><\/span>Indentation<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Indentation is the action where we change the padding between the start of the line of code from the left edge. It is done to increase readability of the code. It provides clear understanding of the contents of a clode block (e.g. <span class=\"lang:default highlight:0 decode:true crayon-inline \">if<\/span>\u00a0 statement, <span class=\"lang:default highlight:0 decode:true crayon-inline \">for<\/span>\u00a0 loop, etc).<\/p>\n<p>The indentation step in this course is 4 spaces. If you use the tab key in, it is recommended to configure your editor to replace a tab with 4 spaces. If tabs are left in, you may encounter your code looking different from one IDE to another (different editors are configured to show tab as 2, 4 or even 8 spaces).<\/p>\n<p><strong>Avoid cross-use of tabs and spaces.<\/strong><\/p>\n<p>The following example is a nicely indented piece of code structure.<\/p>\n<pre class=\"toolbar:2 striped:false marking:false nums:false nums-toggle:false lang:c decode:true\">int main(void)\r\n{\r\n    while (true)\r\n    {\r\n        if (condition)\r\n        {\r\n            stmt;\r\n            break;\r\n        }\r\n        stmt;\r\n    }\r\n    if (condition)\r\n    {\r\n        stmt;\r\n    }\r\n    stmt;\r\n}<\/pre>\n<ul>\n<li>The open and close curly braces are always aligned underneath each other.<\/li>\n<li>The open and close curly brace are on their own lines.<\/li>\n<li>The code block between the curly braces is indented by 1 (4 spaces).<\/li>\n<li>Hint: Most IDEs allow to increase the indentation of 1 or more lines of code by hitting the <span class=\"lang:default highlight:0 decode:true crayon-inline \">tab<\/span>\u00a0 key. They also allow to decrease the indentation of 1 or more lines of code by hitting the <span class=\"lang:default highlight:0 decode:true crayon-inline \">shift+tab<\/span>\u00a0 key combination.<\/li>\n<li><strong>Recommendation:\u00a0<\/strong>configure your IDE in such a way that it will automatically create a closing parenthesis after creating the opening one. If it is not possible, type the closing one immediately so you wouldn&#8217;t forget it. Our geany configuration provides automatic closing of parthesis.<\/li>\n<li><strong>Recommendation:<\/strong> try to indent the code as you type. Most IDEs indent for you as soon as you type { and hit Enter. Having it done automatically avoids mistakes.<\/li>\n<\/ul>\n<h6 data-select-like-a-boss=\"1\"><span style=\"color: #ff0000;\"><strong>Do not do this!<\/strong><\/span><\/h6>\n<p>It is difficult to understand the structure of the code.<\/p>\n<pre class=\"theme:github-copy toolbar:2 nums:false nums-toggle:false copy:false lang:c decode:true\">int main(void){\r\nint i;\r\nfor(i=0;i&lt;10;i++)\r\n{\r\nswitch(i%2)\r\n{\r\ncase 0:\r\nprintf(\"even number\");\r\nbreak;\r\ncase 1:\r\nprintf(\"odd number\");\r\n}\r\n}\r\n}<\/pre>\n<h4><span class=\"ez-toc-section\" id=\"Indentation_depth\"><\/span>Indentation depth<span class=\"ez-toc-section-end\"><\/span><\/h4>\n<p>Avoid nesting (indenting) more than 3 levels. This limit is also used in the industry (sometimes also 4 levels is used).<\/p>\n<p>Excessive indentation makes it hard to follow the code. To combat this, code is refactored by putting parts of it in user-defined functions, combining statements (e.g. nested if statements) or relocating parts of the code.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Loops\"><\/span>Loops<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<pre class=\"toolbar:2 striped:false marking:false nums:false nums-toggle:false lang:c decode:true\">while (condition)\r\n{\r\n    \/\/ do this\r\n}<\/pre>\n<pre class=\"toolbar:2 striped:false marking:false nums:false nums-toggle:false lang:c decode:true\">do\r\n{\r\n    \/\/ do this\r\n}\r\nwhile (condition);<\/pre>\n<pre class=\"toolbar:2 striped:false marking:false nums:false nums-toggle:false lang:c decode:true \">for (int i = 0; i &lt; n; i++) \r\n{\r\n    printf(\"%d\\n\", i);\r\n}\r\n<\/pre>\n<ul>\n<li>Statements <span class=\"lang:default highlight:0 decode:true crayon-inline \">while<\/span>\u00a0 and <span class=\"lang:default highlight:0 decode:true crayon-inline \">for<\/span>\u00a0 are followed by space.<\/li>\n<li>Braces are horizontally aligned (underneath each other).<\/li>\n<li>Braces are on separate lines.<\/li>\n<li>The contents of braces are indented.<\/li>\n<li>In the for statement there should be a space after each semicolon.<\/li>\n<\/ul>\n<h4><span class=\"ez-toc-section\" id=\"Nested_loops\"><\/span>Nested loops<span class=\"ez-toc-section-end\"><\/span><\/h4>\n<p>When nesting loops, you must follow the general indentation guide &#8211; e.g. the contents of each code block is indented.<\/p>\n<pre class=\"toolbar:2 nums:false lang:default decode:true\">for (int i = 0; i &lt; n; i++)\r\n{\r\n    for (int j = 0; j &lt; m; j++)\r\n    {\r\n        printf(\"%d %d\\n\", i, j);\r\n    }\r\n}<\/pre>\n<h3><span class=\"ez-toc-section\" id=\"_Functions\"><\/span>\u00a0Functions<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<h4><span class=\"ez-toc-section\" id=\"main_function\"><\/span>main() function<span class=\"ez-toc-section-end\"><\/span><\/h4>\n<p>Use the <span class=\"lang:c highlight:0 decode:true crayon-inline \">void<\/span>\u00a0 in the parenthesis when you do not intend to accept any command line argument.<\/p>\n<pre class=\"toolbar:2 striped:false marking:false nums:false nums-toggle:false lang:c decode:true\">int main(void)\r\n{\r\n    \/\/ code\r\n}<\/pre>\n<p>Use the following style, with <span class=\"lang:c highlight:0 decode:true crayon-inline \">argc<\/span>\u00a0 and <span class=\"lang:c highlight:0 decode:true crayon-inline \">argv<\/span>\u00a0, only when you intend to pass additional command line arguments (e.g. from the terminal).<\/p>\n<pre class=\"toolbar:2 striped:false marking:false nums:false nums-toggle:false lang:c decode:true\">int main(int argc, char* argv[])\r\n{\r\n    \/\/ code\r\n}<\/pre>\n<h4><span class=\"ez-toc-section\" id=\"User-defined_functions\"><\/span><a title=\"style_anchor_function\" name=\"style_anchor_function\"><\/a>User-defined functions<span class=\"ez-toc-section-end\"><\/span><\/h4>\n<pre class=\"toolbar:2 striped:false marking:false nums:false nums-toggle:false lang:c decode:true\">float CalcPowerConsumption(float current, float voltage)\r\n{\r\n    float power = current * voltage;\r\n    return power;\r\n}<\/pre>\n<ul>\n<li>The function name must explain the purpose of the function.<\/li>\n<li>There are two permitted naming conventions for writing function names\n<ul>\n<li>All words begin with an upper case character. This convetion is called\u00a0<span class=\"lang:default highlight:0 decode:true crayon-inline\">UpperCamelCase<\/span>\u00a0 (also known as <span class=\"lang:c highlight:0 decode:true crayon-inline \">PascalCase<\/span> ). This makes functions distinctive from variables that use <span class=\"lang:default highlight:0 decode:true crayon-inline \">lowerCamelCase<\/span>\u00a0.<\/li>\n<li>All words can be written in lower case, with underscores in between. This convention is called <span class=\"lang:c highlight:0 decode:true crayon-inline \">snake_case<\/span> .\u00a0 This is a widely used classical style for C. NB! If this is used, variables must use the same naming convention.<\/li>\n<\/ul>\n<\/li>\n<li>Each function should have a prototype either before the main() function or in the header file.<\/li>\n<\/ul>\n<h4><span class=\"ez-toc-section\" id=\"Naming_your_functions\"><\/span>Naming your functions<span class=\"ez-toc-section-end\"><\/span><\/h4>\n<p>The name of the function must express what the function does. Most functions start with a verb. E.g.<\/p>\n<ul>\n<li><span class=\"lang:c highlight:0 decode:true crayon-inline\">ReadUsersFromFile()<\/span><\/li>\n<li><span class=\"lang:c highlight:0 decode:true crayon-inline\">CalculateAverageSalary()<\/span><\/li>\n<li><span class=\"lang:c highlight:0 decode:true crayon-inline\">GetTemperature()<\/span><\/li>\n<\/ul>\n<p>Functions returning a boolean value (<span class=\"lang:c highlight:0 decode:true crayon-inline\">bool<\/span> ; true, false; yes, no) start with &#8220;is&#8221;, &#8220;has&#8221;, &#8230; &#8211; the name should read like a yes\/no question.<\/p>\n<ul>\n<li><span class=\"lang:c highlight:0 decode:true crayon-inline\">IsDateValid()<\/span><\/li>\n<li><span class=\"lang:c highlight:0 decode:true crayon-inline\">IsUserAuthenticated()<\/span><\/li>\n<\/ul>\n<p>Naming must be consistent throughout the program.<\/p>\n<h4 data-select-like-a-boss=\"1\"><span class=\"ez-toc-section\" id=\"Function_comments\"><\/span>Function comments<span class=\"ez-toc-section-end\"><\/span><\/h4>\n<p>A multiline comment should precede the function explaining what it does. The comment usually also details the arguments and return value and any possible side-effects the function may have (if any).<\/p>\n<h6>Standard comment<\/h6>\n<pre class=\"toolbar:2 nums:false lang:c decode:true\">\/**\r\n * Description:    Asks the user for an integer in between the given limits.\r\n *                 Repeats until requirements are met and then returns the number.\r\n *                 Outputs a warning when input is out of range\r\n *\r\n * Parameters:     min - lower limit for the user input (inclusive)\r\n *                 max - upper limit for the user input (inclusive)\r\n *\r\n * Return:         Returns an integer within the specified limits\r\n *\/\r\nint GetIntInRange(int min, int max)\r\n{\r\n    int num;\r\n    \r\n    while (1)\r\n    {\r\n        printf(\"&gt; \");\r\n        scanf(\"%d\", &amp;num);\r\n        \r\n        \/\/ Break the loop if input is within expected range\r\n        if (num &gt;= min &amp;&amp; &lt;= max)\r\n        {\r\n            break;\r\n        }\r\n        \r\n        \/\/ Print error when input was not in range\r\n        printf(\"\\nRetry! Input must be in between %d and %d\\n\", min, max);\r\n    }\r\n    \r\n    return num;\r\n}<\/pre>\n<ul>\n<li>Description &#8211; states the purpose, limitations and the workings of the function. Any data altered that&#8217;s not local to the function must also be specified (e.g. arrays).<\/li>\n<li>Parameters &#8211; their names and semantics (what are they used as in the function). Any requirements for the values passed should also be specified!<\/li>\n<li>Return value &#8211; data type and semantics<\/li>\n<\/ul>\n<h6 data-select-like-a-boss=\"1\">Shortened form<\/h6>\n<p>Shortened form should only be used for very basic functions.<\/p>\n<pre class=\"toolbar:2 striped:false marking:false nums:false nums-toggle:false lang:c decode:true\">\/**\r\n * Function to calculate the power consumption given\r\n * the voltage and current the circuit is using.\r\n *\/\r\nfloat CalcPowerConsumption(float current, float voltage)\r\n{\r\n    return (current * voltage);\r\n}<\/pre>\n<h4><span class=\"ez-toc-section\" id=\"Function_prototypes\"><\/span>Function prototypes<span class=\"ez-toc-section-end\"><\/span><\/h4>\n<pre class=\"toolbar:2 striped:false marking:false nums:false nums-toggle:false lang:c decode:true\">float CalcPowerConsumption(float current, float voltage);<\/pre>\n<ul>\n<li>You should make a prototype for each of your functions.<\/li>\n<li>Naming convention is the same as for functions.<\/li>\n<li>Both type and name should be listed for parameters.<\/li>\n<li data-select-like-a-boss=\"1\">Prototypes of your functions should be listed in a separate header file (recommended) or in the .c file after the preprocessor directives (#include, #define).<\/li>\n<\/ul>\n<h3><span class=\"ez-toc-section\" id=\"Enumerations\"><\/span>Enumerations<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Declarations of the enumeration type should be written using <span class=\"lang:default highlight:0 decode:true crayon-inline\">PascalCase<\/span>\u00a0 &#8211; all words begin with an upper case character, words are written without spacing. All type names must be written in singular.<\/p>\n<p>The identifiers should be in <span class=\"lang:default highlight:0 decode:true crayon-inline\">SCREAMING_SNAKE_CASE<\/span>\u00a0 &#8211; all upper case characters, separated by underscores.<\/p>\n<p>Use either a single-line definition style<\/p>\n<pre class=\"toolbar:2 nums:false lang:default decode:true\">enum SystemStatus {STATUS_OFF, STATUS_IDLE, STATUS_BUSY};<\/pre>\n<p>or a multiline definition style.<\/p>\n<pre class=\"toolbar:2 nums:false lang:default decode:true\">enum SystemStatus \r\n{\r\n    STATUS_OFF,\r\n    STATUS_IDLE, \r\n    STATUS_BUSY\r\n};<\/pre>\n<p>Note: in general, avoid using <span class=\"lang:default highlight:0 decode:true crayon-inline \">typedef<\/span>\u00a0 to redefine the name of the enum. Redefinition hides that it is an enumeration type.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Structures\"><\/span>Structures<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Structures use the same rules for declaration as enumeration, i.e. the names must be in singular form an are written in <span class=\"lang:c highlight:0 decode:true crayon-inline \">PascalCase<\/span> . Struct members are written with the same rules as are variables. Common Indentation rules also apply.<\/p>\n<pre class=\"toolbar:2 striped:false marking:false nums:false nums-toggle:false lang:c decode:true\">typedef Person\r\n{\r\n    char *fName;\r\n    char *lName\r\n    uint_64t identityCode;\r\n};<\/pre>\n<p><strong>DO NOT<\/strong> use the suffix <span class=\"lang:c highlight:0 decode:true crayon-inline \">_t<\/span>\u00a0 when naming your stucts. This is reserved for the language itself and can cause conflicts.<\/p>\n<p>Note! Even though using\u00a0is considered hiding information, in the case of structures and unions it is acceptable within this course.<\/p>\n<p>If you wish, you are allowed to redefine the type name using <span class=\"lang:default highlight:0 decode:true crayon-inline\">typedef<\/span> . Keep in mind, that doing so might be considered a mistake or in bad style! This is because it deliberately hides information &#8211; it will no longer be visible that it&#8217;s a struct.<\/p>\n<pre class=\"toolbar:2 striped:false marking:false nums:false nums-toggle:false lang:c decode:true \">typedef struct Person\r\n{\r\n    char *fName;\r\n    char *lName\r\n    uint_64t identityCode;\r\n} Person;<\/pre>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Introduction The main purpose of a coding style (or coding standard) is to ensure that the work of multiple contributors within a project (or a company) produces code that is uniform in style. That increases the readability of the code and makes it easier for others to update the code if\/when that should become necessary. &hellip; <a href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/coding-style\/\" class=\"more-link\">Loe edasi <span class=\"screen-reader-text\">Coding style<\/span> <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":4802,"menu_order":1,"comment_status":"closed","ping_status":"closed","template":"page-templates\/code-width.php","meta":{"footnotes":""},"class_list":["post-1592","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/blue.pri.ee\/ttu\/wp-json\/wp\/v2\/pages\/1592","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blue.pri.ee\/ttu\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/blue.pri.ee\/ttu\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/blue.pri.ee\/ttu\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blue.pri.ee\/ttu\/wp-json\/wp\/v2\/comments?post=1592"}],"version-history":[{"count":8,"href":"https:\/\/blue.pri.ee\/ttu\/wp-json\/wp\/v2\/pages\/1592\/revisions"}],"predecessor-version":[{"id":11422,"href":"https:\/\/blue.pri.ee\/ttu\/wp-json\/wp\/v2\/pages\/1592\/revisions\/11422"}],"up":[{"embeddable":true,"href":"https:\/\/blue.pri.ee\/ttu\/wp-json\/wp\/v2\/pages\/4802"}],"wp:attachment":[{"href":"https:\/\/blue.pri.ee\/ttu\/wp-json\/wp\/v2\/media?parent=1592"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}