DEV Community

Angel Oduro-Temeng Twumasi
Angel Oduro-Temeng Twumasi

Posted on • Edited on

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

#c #programming #beginners #codenewbie

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;
}

This a good example
Enter fullscreen mode Exit fullscreen mode

if (condition)
{
statement1;
statement2;
}


This applies to functions as well. An example is the main function
Enter fullscreen mode Exit fullscreen mode

int main(void)
{
return (0);
}

- 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.
Enter fullscreen mode Exit fullscreen mode

do {
body of loop;
} while (condition);

- Don't use braces for when a single statement is written in 
An example is the code below
Enter fullscreen mode Exit fullscreen mode

if (condition)
statement;

It applies to this as well
Enter fullscreen mode Exit fullscreen mode

if (condition)
statement;
else
statement;

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

if (condition)
{
do_this();
do_this();
}
else
{
do_this();
}


- Don't use commas on a single line to avoid braces
Enter fullscreen mode Exit fullscreen mode

if (condition)
do_this(), do_this();

Do this instead
Enter fullscreen mode Exit fullscreen mode

if (condition) {
do_this();
do_this();
}


### 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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xj08kns1wwrp7mldlb07.png)

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

a = sizeof( struct file );

This is a good example
Enter fullscreen mode Exit fullscreen mode

a = sizeof(struct file);


- Use one space around most binary and ternary operators such as :
Enter fullscreen mode Exit fullscreen mode

= + - < > * / % | & ^ <= >= == != ? :

- Do not use spaces around **_unary operators_** :
Enter fullscreen mode Exit fullscreen mode

& * + ~ ! sizeof typeof alignof attribute defined


- Do not leave trailing whitespace at the end of lines else you'll receive the following warning from betty


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/smy3rpnsw2cpxm573xut.png)

### 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
Enter fullscreen mode Exit fullscreen mode

/* This is a single line comment */

Enter fullscreen mode Exit fullscreen mode

/**

  • This is a multiline comment
  • comments in C source code */

## 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.
Enter fullscreen mode Exit fullscreen mode

/**

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

int main(void)
{
printf("Hello");
return (0);
}


- If the function must return a value, the `Return:` header tag is **mandatory**

- Arguments supplied to functions must be added to their respective tags.
Enter fullscreen mode Exit fullscreen mode

/**

  • sum - Calucates the sum of two numbers
  • @arg1 - First operand
  • @arg2 - Second operand *
  • Return: The sum of the two parameters */

- You could add additional sections like `Example` which you could give examples of the usage of your function
Enter fullscreen mode Exit fullscreen mode

/**

  • 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);
}


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](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/process/coding-style.rst)

Follow me on [Github](https://www.github.com/angelotheman), let's get interractive on [Twitter](https://www.twitter.com/_angelotheman) and form great connections on [LinkedIn](https://www.linkedin.com/in/angelotheman) 😊
Enter fullscreen mode Exit fullscreen mode

Top comments (16)

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
 
darth-jade_i profile image
Solomon Ovie Okomowho •

This is fantastic!!!! can I share this article on my page?

Collapse
 
angelotheman profile image
Angel Oduro-Temeng Twumasi •

Under condition that you attribute the authorship to me. You can share the knowledge.

Also reach out to me on my socials let's discuss if you want me to write for your agency

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 😊

View full discussion (16 comments)

Read next

mukhilpadmanabhan profile image

No-Code Tools: Should Developers Worry or Embrace the Future?

Mukhil Padmanabhan -

valeriavg profile image

Day 9: Terminal Forms 📇

Valeria -

zirkelc profile image

Buffer Logs and Flush Automatically on Error with Powertools for Lambda

Chris Cook -

shanewen profile image

New to Dev.to. What do you usually do here?

Shane Wen -