Home Home > 2014 > 02 > 19 > Code quality and Code guidelines
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Code quality and Code guidelines

February 19th, 2014 by

Today I like to take you precious time to talk about thing that get so less attention in open source world. I like to talk little bit about QA and Coding guidelines.
Many reader who are in companies that take care of themselves or are involved some major open source or free software project like KDE, GNOME or Linux kernel knows that they/we have Coding guidelines. KDE have it here and Kernel have it here. So they have them and whats the big deal?

Why have code guideline and hang on it?

I’ve been coding since I was kid. I didn’t know better way to waste my time that sitting front of Commodore 64 and hack together some BASIC code and my code was horrible.
I didn’t have any clue how to organize it or how to make it more readable (BASIC ain’t that BASIC when you try to read it afterwards). Years after some major Assembly experiences on 286 and 386 I found Pascal. Then I understood one thing. If you don’t understand your stuff you write you don’t understand it after a while! So I tried to be more constructed what I did (Pascal/Delphi still have soft spot in my heart.. always!) and forget it sort after that for almost 10 years.

Doing it professionally

If you code for living you have to be very sure you can read your code and others can also. You can stop developing your code after that someone else can come to maintaining that particular code and this is situation in open source most of the time.
You never know how long you code will be used, forked or maintained by someone else brave after you have moved on to something more interesting.
Following code guidelines is not very difficult. You just forget about your excuses about beauty of your code and ignorance about making code look solid with rest of application. Most horrible
is read some code that where you have to learn how different people write code and their definition about good code guidelines.
If you lazy like me you can use tools like:

I do want my code to look like I did it

No you don’t if you contribute to someone else project you make you code look like his or her code. Structured code is always looking good.
We have policy that version control system make decision how code should look like. So there is some tool and version control hook script that structures code to what is our stated our code guidelines and believe me it have worked better than I expect. People still have to make changes but you have reply what is wrong. No more rants about what is correct looking code and people giving me excuses why code is not following code guidelines. There is only one that have dictatorship here and it’s version control system and 99.9% it does good job.

Code guidelines are not equal Code quality

No they are not. They have nothing to do with Code quality control or do they? openSUSE Build service have very good for everyone to take good example. To make your RPM package SPEC-file compile to binary or source RPM you have to follow machine checked rules. If you correct at least those it will be all okay. Scripts check that you don’t have million bytes long jargon in Summary-line or you have Summary-line at all. They run rpmlint and check C-code for some we’ll known problems. If they are qualified enough to go through this you won’t get your RPM/DEB/Arch-package.
Now we can argue long time do static code checking have any value but long time user of static code checking tools like cppcheck I can tell static analyzing find many that people just ignore to find because they don’t have time to thing whole logic or understand that memory handling issue.
Best way to use them I again run them on version control system hook before code gets in. It won’t make code perfect but you make developer fear for commiting and when developer fear they make better code.
After you have structured code and machine checks it statically it’s much easier to get in to point and find problems. So you can talk about what is really wrong or right with code. It’s easier to read some text if that have passed thesaurus in Libreoffice and again openSUSE obs policy is very very efficient. It spots stuff that you don’t care about and yes I miss SPEC code structure-script in OBS but you can’t have all.
Now it’s time make code guidelines to you project and use some tool to make all project look like it (My opinion is that have always some for example Artistic Style tool example how to structure code for your with code guidelines) and that FFmpeg stuff is coming when I feel it’s ready to rock!

Both comments and pings are currently closed.

2 Responses to “Code quality and Code guidelines”

  1. I always say that you should write your code as if the person maintaining it is a psychopath with an axe and your home address.

    • Yes very true. First time you end up maintain 10+ years old system with several people not giving a damn about anything about code sanitation you will know that is so true.