Wednesday, March 9, 2011

Writing neat code!

Hey guys.. this post shows or tells how to write a neat piece of code! neat as not in optimisation or fast blah blah.. its about the code looks on the IDE and quite understandable to everyone whoever reads!
  • the IDE (integrated development environment) plays a major role. that's what helps you in present a great code great! i always used JFE (jen's file editor), now in my MSc i need to use Visual Studio 2010 or 2008. i loved the unique feature of visual studio. just copy and paste the entire source code in your documentation file like .doc or .docx it gives a good syntax highlighted format.

  • use specific tab spaces। like 2 ,4 ,8 depending on the length of code. and specify them neatly.

  • use good indentation style. i would prefer BSD KNF style. saves line over silly "{", but i need to add comment at the end of closing braces like "}// end if". and using indentation tabs to 4 or 2 looks pretty good.

  • use good variable-names function-names. the way i prefer variable names is my-Purpose-number-data direction-features example: sonarIn1; crispOutLeft; for small loops u could use a,b,c,d... which are really negligible. : wow.. looks quite long right! yea, i too felt this way when i started programming writing silly a=0, b=0; but writing huge code for 500-1000000 lines. u will need this. and practice this right now.
  • for functions i would prefer something like this.. the first set describes what the function is doing, next describe where is it doing. describing the function name well will give quite an understanding! some times i even prefer the word my this can differentiate easily whats an in-built function and your function. like myprintf() .. this can easily explain things.. as u know the printf function, u could understand what myprintf does. Eg: getSonarReading(), doDefuzzification(), getDOMSingleton().
  • follow the requirement specification for code. different people will need different styles of coding. in one such assignment (case), i was needed to have max limit of 80 characters in a line, which i could do quite well with indentation tabs or 4 or 2.

  • // good comments. the most key part for understanding a code. software engineers say 75% of your source code file should be filled with comments! and rest the code.

  • specify everything in your comment. leave a big green patch over every source code you write. detailing about every single bit you've used from compilers to library, revision version, date, improvements, how to compile, how to run, indentation style, resources,... so on! make sure than any monkey with your code can compile and run it.

some examples of my comments! i feel they r OK!


Saturday, March 5, 2011

Basic debugging hints



Okay, getting to know what your embedded device or program is doing is very much important when debugging. i went through ups and downs to get a good debugging etiquette. in windows or UNIX programming printf() helps really well,
what if there is a while loop and you need to check every point step by step. there another one such thing called the getche(). these functions come really handy when debugging embedded stuff and look into the problem step by step.
  • printf() can really come handy. but while debugging a huge set of inputs its quite hassle to get all the input shooting over the screen. rather than using printf("blah blah ... \n"); you could replace \n with a neat \r. it simple returns the character blinky thing to the start position. voila things look pretty neat now! Some of my screen shots here.

[top] pretty bad stuff.. this could ruin the computational speed of the program. I suffered quite with this. the simulated robot was all going slow.


[top] with the replacement of \n to \r made things look pretty well.
  • even the \a "alarm bell" helps a lot to observe minute things. it never worked in Visual Studio 2010. but works well for UNIX systems.
the getche() is also useful. the functions just sits until the user presses a key. if you could add put these here and there when you are debugging. the actual break point can be observed.


P.S: you will need to #include for getche()