Showing posts with label gnu. Show all posts
Showing posts with label gnu. Show all posts

Friday, June 8, 2012

About Coding Standards - C++

Whenever you write an article or an essay, you are conforming to language standards. Some are required, and other are preference. Using a semicolon is required. Choosing whether or not to split the sentence into two instead of conjoining them with a semicolon, however, is just your own opinion. You do it to fit in with a crowd. Some believe that the use of thee semicolon in the English language shows mastery and intelligence, but others may think that it is reckless for whatever reason. Coding standards are similar to this.

When you write a program you are, in essence, writing a very technical essay detailing how to do a specific task. This essay, like in the English language, have preferences you can choose from. You can choose to write a program like this:
int num1=0;int num2=0;for(int i=0;i<10;i++)cout<<num1+num2<<endl;
That could also be written like this:

int num1=0;
int num2=0;

for(int i=0; i<10; i++)
    cout << num1+num2 << endl;

This is exactly the first jumble of code, but more readable. We used a formatting style to make this example more readable than the first. We all know that the semicolon (in programming) should always be at the end of the line (except for the exception of initialization within loops). This is a major standard. What are some of the minor ones, though?

Group Types
I am the type of person that puts all of the variables at the top of a function. Some prefer to make them when they are needed, but I like seeing everything that this function will do before it does it, like an outline. I group variables based on their types,  and I encourage others to do so as well. They should also be related in function, so all numerical types come before text types.When you run out of a certain type, it is good practice to include a line of whitespace. I group pointers by being a pointer, not type.

int num1 =  0;
int num2 =  0;

double d1= 0;
double d2= 0;

char c1     = 'a';

char *pc1 =&c1;

This raises another very minor point. I put "*" near the variable name instead of anywhere else. This way, you can clearly see that it is a pointer.

Indent a space
Within nested loops, I indent one space for each level. Also, I ALWAYS put a bracket, even if it is a one-line loop. I begin the bracket on the same line as the loop and each on its own line, sometimes with comments.

for(;;){
 for(;;){
  for(;;){
   for(;;){
              }//END for
            }//END for
          }//END for
        } //END for

Operator Aligning
Whenever I get input with cin and use cout to output it, I always align the "<<" and ">>"'s. Sometimes I do this with semicolons, equal signs, and comments, but this is not always the case. This is more obvious if a block of code is designed for one task. After blocks of code, make a line of whitespace.

cout << "Enter Item: ";
cin    >> item                 ;
cout << item <<endl   ;

Putting it all together
Here is what a sample program should look like:

#include <iostream>
using namespace std;
int main(){

 int num1=0;
 int num2=0;

 char char='a'; 

 for(int index=0; index < 10; index++){
  int inlineInt       ;
  inlineInt=index;

  cout << "Enter a whole number: "<<endl;
  cin    >> inlineInt                                             ;
  cout << endl                                                      ;
 }//END for
}

There are many different coding standards out there. K&R, GNU, and Java are just a few. Over the course of your work you will develop your own style. What I have shown you today is my preferred style. You can adopt it if you wish, but it would be a more rewarding experience to write a few programs and see which works best for you. Lazy people and beginners do not follow any sort of standard, and that makes the code very unpleasant to see and work with later on just as much as not commenting it does.

Saturday, June 2, 2012

Open Source Development Model

Many people do not understand what the term "Free" (in the sense of libre) means to the fullest of its power when it relates to software. Many confuse it with free as in free beer, or "gratis" as Linux creator Linus Torvalds calls it. This is an in-depth comparison between the two terms and how it relates to software.

Common misconceptions
Whenever I bring up the subject of open-source software with somebody who does not write code, they always use the same argument. "So, what? You don't think that people should be rewarded for what they do?" In fact, this is why many people associate open-source supporters with the communist party. However, this is not the case. Projects where a lot of the code is open-source (such as OS X or Android) still generate tons of cash. Advertising also draws a huge monetary gain for open-source developers.  In all revisions of the GNU GPL selling free software is strongly encouraged, showing that it can and is done.

Simply releasing the code does not make a program free (in the definition of the Free Software Foundation). To be free it must be licensed under a license that stops it from becoming proprietary in the future. In my "travels" I met a man that was a fan of the BSD license, boasting that it was even more free than the GNU GPL. However, the project he was referencing was not original. Had it been a few years later that he decided to maintain the project, it may have already become depracted by a proprietary variant.

Unlimited Potential
The difference in the development models of proprietary and open source development is described in "The Cathedral and the Bazaar". They differ in one key area: who writes the code.

In a closed-source development model, a developer or team of developers work on one copy of a product and release it to the public. Only they can monitor the code and they are wholly responsible for fixing bugs and making the code more efficient. This costs man hours, and it is why a lot of payed programs are proprietary.

On the other hand, Open Source development happens in a much more community-esque fashion. An author or team of authors conceives a product and begin development, and either immediately or at a point where the barebones functionality has been met they release it to the public under a free license. Up to this point the style this happens is much like a closed-source model, but the magic of open source occurs at the next step. Any hobbyist or paid programmer (some companies actually pay developers to write free code) in the world (if it is hosted on the internet) can write bug fixes and new features for the program. They can also host their own variant of the program if they feel their addition changes the functionality or aesthetics too much.

The Downside
The weakness of the Open Source model is the same as its strength: anyone can see the source. Crackers, malaware authors, or anyone wishing to break a system can analyze the code, find the weaknesses, and write exploits for them. However, whenever a gap is released it is usually spotted and squashed within weeks.