Code Styles

Photo by Fahrul Razi on Unsplash

Code Styles

Welcome to the series "Clean Code"; brought to you by "Coding Mantis"!

Imagine that you were forced to read a book. It's safe to assume that you wouldn't enjoy reading it and you'd probably struggle to understand it if it was all typed out in one sentence, or in one line, or lacking punctuation. Heck; imagine if some words were alternating between lower and capital case letters. Chaos, right?

I think we can agree that you wouldn't opt-in to read anything if it was not properly formatted.

So why should your code be any different? Hint; it shouldn't.

Mind blowing

Enter — Code styles.

What is a code style?

Much like any publication, code has a small set of rules that are defined by a software engineer (or more if we're talking about a team) prior to writing it. There are some general conventions or guidelines amongst the community but it's generally the team or the individual that defines it.

This set of typing rules is called a code style.

How would I know what's right or wrong in my case?

If you're in a team, I'd strongly suggest you sit down with your team, discuss the approach you want to take, and find a style that suits your needs. Remember, code should always be easy to read. It should also be easy to understand but this is a topic for another post.

I'm not sure I understand, can you show me an example?

I can and I will.

This topic is language agnostic but I'll demonstrate a small dummy example in Java, which you can adapt to your own needs.

void foo(int x, int y){
  var xyHolder= XYHolder.builder().withX(x).withY(y).build();
  if(xyHolder.getX()==1)System.out.println("Fizz");
  else if(xyHolder.getY()==2)System.out.println("Buzz");
  else System.out.println("FizzBuzz");
}

There are all sorts of things going wrong in the above example but having read it you probably understand what it does. But, was it easy or enjoyable to do so?

I guess not, and in truth, not many people type code like this, but how can you make it better?

If you sit down either on your own or with your team and define some rules about it, it should become pretty clear; for example:

  • chained invocations of builder methods on separate lines would allow for readability
  • adding some whitespace would let your code breathe
  • wrapping single line code branches in curly braces would make nested statements pop-out
void foo(int x, int y) {
  var xyHolder = XYHolder.builder()
    .withX(x)
    .withY(y)
    .build();

  if (xyHolder.getX() == 1) {
    System.out.println("Fizz");
  } else if (xyHolder.getY() == 2) {
    System.out.println("Buzz");
  } else {
    System.out.println("FizzBuzz")
  }
}

Looks better already, right? It may appear longer, but it's not; what we did here was to make it more readable.

Conclusion

Regardless of whether you work alone or in a team, having a defined clear code style will allow other people to read it afterwards, even if that other person is your future self.

What do you think about the subject?