DEV Community

Angel Oduro-Temeng Twumasi
Angel Oduro-Temeng Twumasi

Posted on • Updated on

The Art of Clean Code: Mastering the Betty Style 🧑🏾‍💻

Introduction

When it comes to developing software in any programming language, adhering to a consistent coding style is crucial for maintaining readability, collaboration, and code quality. For the C programming language, one widely recognized coding style is known as Betty. Betty, originally created for the Linux kernel development, has become popular within the C programming community, providing a set of guidelines to enhance code clarity and maintainability.

What is Betty?

Betty is a coding style guide specifically tailored for the C programming language. It was devised to standardize coding practices within the Linux kernel development community, ensuring that the codebase is cohesive and comprehensible to developers working on the project.

The Importance of Consistent Style:

Consistency in coding style plays a vital role in collaborative projects, making it easier for team members to understand and modify each other's code. Betty enforces a standardized set of rules, including naming conventions, indentation, spacing, and comment placement. By following these guidelines, developers can produce clean, readable code that is more approachable to others and less prone to errors.

Set up betty on local machine.

  • Clone the betty repo
  • cd into the Betty directory
  • Install the linter with
sudo ./install.sh
Enter fullscreen mode Exit fullscreen mode

Run the following commands to check if your code/doc fits the Betty Style:

betty-style <filename>
Enter fullscreen mode Exit fullscreen mode
betty-doc <filename>
Enter fullscreen mode Exit fullscreen mode

Let's look at a simple guide for coding using the Betty style

Indentation

Imagine looking at a codebase for more than 20hrs. Indentation helps you to easily identify which parts to find information quickly. This really helps with debugging

  • Use TAB to indent your code. A block of code is every group of statements inside a set of curly braces ({})

An example is what is used in our main function

int main(void)
{
        return (0);
}
Enter fullscreen mode Exit fullscreen mode
  • Do not put multiple statements on a single line

This is a bad example

if (condition) do_this;
do_something_everytime;
Enter fullscreen mode Exit fullscreen mode

This is a good example

if (condition)
     do_this;

do_something_everytime;
Enter fullscreen mode Exit fullscreen mode
  • In the case of multiple indentation statements - the switch statement -, the switch keyword and it's subordinate case are placed on the same indentation levels as shown in the example below
int add(int sum)
{
        var i = 0;
        switch (sum)
        {
        case 23:
                i = 34;
        default:
                i = 4;
        }
        return var;
}
Enter fullscreen mode Exit fullscreen mode

The use of braces {}

  • Opening and closing braces should be placed at the beginning of the next line. This is a bad example
if (condition) {
        statement1;
        statement2;
}
Enter fullscreen mode Exit fullscreen mode

This a good example

if (condition)
{
        statement1;
        statement2;
}
Enter fullscreen mode Exit fullscreen mode

This applies to functions as well. An example is the main function

int main(void)
{
        return (0);
}
Enter fullscreen mode Exit fullscreen mode
  • The body of the braces should be indented as stated in the above examples.

There are exceptions to this rule however. If a continuation of the same statement follows the ending braces, you need to add it. An example is the do....while statement.

do {
        body of loop;
} while (condition);
Enter fullscreen mode Exit fullscreen mode
  • Don't use braces for when a single statement is written in An example is the code below
if (condition) 
        statement;
Enter fullscreen mode Exit fullscreen mode

It applies to this as well

if (condition)
        statement;
else
        statement;
Enter fullscreen mode Exit fullscreen mode

Note that this doesn't apply where the even one has multiple statements. An example is

if (condition)
{
        do_this();
        do_this();
}
else 
{
        do_this();
}
Enter fullscreen mode Exit fullscreen mode
  • Don't use commas on a single line to avoid braces
if (condition) 
   do_this(), do_this();
Enter fullscreen mode Exit fullscreen mode

Do this instead

if (condition) {
        do_this();
        do_this();
}
Enter fullscreen mode Exit fullscreen mode

Use of spaces

  • Use space after these keywords if, else if, switch, case, for, while, return.
  • Do not use space however after the following which look like functions: sizeof, typeof, alignof and __attribute__.

Here's a table for reference

Image description

However, do not use spaces around (inside) expressions.
This is a bad example

a = sizeof( struct file );
Enter fullscreen mode Exit fullscreen mode

This is a good example

a = sizeof(struct file);
Enter fullscreen mode Exit fullscreen mode
  • Use one space around most binary and ternary operators such as :
= + - < > * / % | & ^ <= >= == != ? :
Enter fullscreen mode Exit fullscreen mode
  • Do not use spaces around unary operators :
& * + ~ ! sizeof typeof alignof __attribute__ defined
Enter fullscreen mode Exit fullscreen mode
  • Do not leave trailing whitespace at the end of lines else you'll receive the following warning from betty

Image description

Breaking of long lines of character

Coding is all about readability and maintainability. Lines of code should not be very long such that one needs to scroll laterally to read them.
The limit on the lines is 80 columns and is strongly the preferred limit

Functions

Functions are simply a chunk of code that does one particular thing.

  • Functions must contain not more than 40 lines of code
  • Local variables in a function shouldn't exceed 5-10
  • When using source file, separate functions with one blank line

Commenting in C

/* This is a single line comment */
Enter fullscreen mode Exit fullscreen mode
/**
 * This is a multiline comment
 * comments in C source code
 */
Enter fullscreen mode Exit fullscreen mode

Code Documentation

The use of documentation in programming is very necessary for anyone to be able to understand the code very well. We provide documentation by way of commenting. By adding comments at key points, you provide context, explanations, and insights that clarify your code's purpose, intentions and intricacies.

Betty has a style for documenting your code. Let's look at them

How to document functions

Instead of a regular C multiline commenting, the comment block for the documentation would look like this.

/**
 * main - This is the entry point of the code
 *
 * Return - 0 Successful
 */

int main(void)
{
        printf("Hello");
        return (0);
}
Enter fullscreen mode Exit fullscreen mode
  • If the function must return a value, the Return: header tag is mandatory

  • Arguments supplied to functions must be added to their respective tags.

/**
 * sum - Calucates the sum of two numbers
 * @arg1 - First operand
 * @arg2 - Second operand
 *
 * Return: The sum of the two parameters
 */
Enter fullscreen mode Exit fullscreen mode
  • You could add additional sections like Example which you could give examples of the usage of your function
/**
 * Sum- Makes the sum of two numbers
 * @arg1: First operand
 * @arg2: Second operand
 *
 * Return: The sum of two parameters
 *
 * Example:
 *    sum(10, 5); --> 15
 */

int sum(int num1, int num2)
{
        return (num1 + num2);
}
Enter fullscreen mode Exit fullscreen mode

Using the Betty Coding style is extremely beneficial as a programmer. It ensures that your codes are consistent, readable and have great clarity.

I believe this was a great read for you especially if you are a C programmer and a student of ALX Software Engineering and Holberton School. Like and comment if you found it helpful.

Read more about the style of coding from the Linux Kernel coding style

Follow me on Github, let's get interractive on Twitter and form great connections on LinkedIn 😊

Top comments (14)

Collapse
 
pauljlucas profile image
Paul J. Lucas

The style for documenting code should be the de facto standard of Doxygen.

Collapse
 
angelotheman profile image
Angel Oduro-Temeng Twumasi

I see that. I just read and it has some interesting notes in there. But I still believe, Betty has the best of both worlds.

Code styling and documenting

Collapse
 
pauljlucas profile image
Paul J. Lucas

For formatting, clang-format is the de factor standard.

Thread Thread
 
angelotheman profile image
Angel Oduro-Temeng Twumasi

Interesting one. I gave a resource in the write-up, you can check it out.

Collapse
 
mxglt profile image
Maxime Guilbert

Always useful to share the noble art of clean code. By sharing this kind of standards we are sure that anyone can read any code.

Collapse
 
angelotheman profile image
Angel Oduro-Temeng Twumasi

Yeah Maxime. Clean code should be advocated. If you want to be a good programmer, be good at writing clean codes.

This makes code interpretation easy and hence working on the code doesn't become tedious

Collapse
 
jeff_barnes_3afd3fb0c5f9f profile image
Jeff Barnes

The 'use of braces' section is wrong. It should only have start brace on the next line for functions, not statements.

Collapse
 
angelotheman profile image
Angel Oduro-Temeng Twumasi • Edited

I love that you comment on this post. However, I would plead you get your facts right.

You can go to the links I shared read about it. This article is C programming and the Betty coding style.

Collapse
 
jeff_barnes_3afd3fb0c5f9f profile image
Jeff Barnes

This article claims this conforms to the Linux Kernel code guidelines. I was just pointing out that it doesn't.

Thread Thread
 
angelotheman profile image
Angel Oduro-Temeng Twumasi

In what ways does it not? Remember that this is Betty Coding Style

Collapse
 
daveasiamah profile image
David Asiamah

I think most of the rules regarding formatting can be handled by a linter.

Collapse
 
angelotheman profile image
Angel Oduro-Temeng Twumasi

The Linter is also a great one. However I think Betty has an edge as it not only check the formatting, but it checks the docs as well.

In fact, Aunty Betty makes you adhere to strict coding protocols 😀

Collapse
 
beanalby profile image
Jason Viers

Functions must contain 40 lines of code

Functions must FIT IN 40 lines. So they have to be less than 40, not greater than 40. Confused the heck out of me at first.

Collapse
 
angelotheman profile image
Angel Oduro-Temeng Twumasi

Error corrected. Thank you for pointing that out 😊