[bodom658]

Formatting, and over commenting. people should explain what the program does at the top, and just have small bits of explanation through the rest. I don't need a paragraph about what your while loop does.

[TheMagnitude]

IrishCereal, on 9 Feb, 2009 - 03:14 PM, said:

I honestly do not understand why people do this:

if (condition)
  {
  statements
  }

I like it better and think it looks a lot nicer like this:

if (condition) {
  statements
}

I prefer a variation of the first:

if (condition)
{
  statements
}

I think that looks very neat and its very easy to tell where blocks of code start and end when you start nesting loops and what not.

My code has to be perfect! And therefore everyone elses. Proper indentation is a big one here, if you don't indent your code it makes it pretty much unreadable at first sight. And when your trying to help someone who hasn't indented there code I generally just move on to the next topic or post a reply telling them to SORT OUT THERE LIFE!

What really drives me mad is when people use others code snippets solely because they can't be bothered to learn how to do it themselves. Whenever I come across a hurdle in a program, I jump over it myself, yeah, quite alot of the time I ask for a little leg up from DIC to point me in the right direction, but I don't just copy and paste someone elses code. How will you learn like that? I love the feeling that when I've written a program and it's all my own code, it makes me so proud , thats why I try not to use anyones elses.

[5ubw0r1d]

IrishCereal, on 9 Feb, 2009 - 03:14 PM, said:

I honestly do not understand why people do this:

if (condition)
  {
  statements
  }

I like it better and think it looks a lot nicer like this:

if (condition) {
  statements
}

Yes. So much nicer. And I agree with baavgai "} // end loop" is horrible and unecessary if you properly indent your code.

Another pet hate in OPC is OP's failure to understand basic loop and boolean logic.

Example

var flag = True;

while(flag != True){
	statements;
}

Should be

var flag = True;

while(!flag){
	statements;
}

This post has been edited by 5ubw0r1d: 09 February 2009 - 05:07 PM

[scalt]

As far as comments go, I find the single, most helpful thing any coder can do is put a comment at the beginning of each method/function/class or even large blocks of code explaining what it does. Usually it only takes a sentence or two (anything longer gets pointless) and it makes it so much easier for anyone trying to figure out what you were doing.

Just thought I'd mention that because they never covered it at Uni, they just said 'comment your code'. I would agree that stupid little comments on every second line make it infinitely harder to understand what the hells going on.

This post has been edited by scalt: 09 February 2009 - 04:58 PM

[thepeoplescoder]

Gloin, on 9 Feb, 2009 - 03:29 PM, said:

IrishCereal, on 9 Feb, 2009 - 11:14 PM, said:

I honestly do not understand why people do this:

if (condition)
  {
  statements
  }

I like it better and think it looks a lot nicer like this:

if (condition) {
  statements
}

YES YES YES!!! AAaaaaarrrgghh

I totally agree.

if (condition) {   // Form #1 - Good
   statements
}

if (condition)   // Form #2 - Good
{
   statements
}

if (condition)   // Form #3 - Absolutely BAD.  What statement does it belong to?
   {
   statements
   }

// Although forms 1 and 2 work good for conditionals and loops,
// form #1 should not be used with functions.  Form #2 is fine, though.

// Form #2 - This form works great for functions, and methods.
int main(void)
{
   statements
   return something;
}

// Form #1 - This form is fugly for functions and methods.
int main(void) {
   statements
   return something;
}

// However, it's somewhat okay for small classes and instance methods, when the
// code is written inside of the class.
class Something : public BaseSomething
{
private: // Visual C++ Express auto-indents this to the first column.
   int myValue;

public:
   // Two short statements or less, so this form is fine.
   Something() {}
   Something(int val) { myValue = val; }

   void SetValue(int value) { myValue = value; }
   int GetValue(void) { return myValue; }

   // I don't know how some programmers view this form in C++.
   // I find it slightly tolerable from tinkering with D and with properties
   // in C#.
   //
   // void Value(int value) { myValue = val; }
   // int Value(void) { return myValue; }
};

If your programming language uses braces, ALWAYS make sure that the closing brace matches the column of the statement that it corresponds to. Otherwise, if the language uses some type of end construct instead, make sure that the column of the end matches the column of the statement that it corresponds to as well.

ALSO, another thing, when it comes to form, stick to one style and remain consistent throughout your program. If you decide you wish to change styles later on, change EVERYTHING in your source code to match that new style, or, don't adopt the new style until you start on a new project.

As far as indentation is concerned, pick either tabs or spaces, and stick with it. For most languages, I would recommend tabs, since each IDE has their own internal way of handling it, and it keeps the look of your code consistent across IDEs.

As far as Ruby and Python are concerned, don't use tabs. The accepted convention for indentation is 2 spaces for Ruby, and 4 spaces for Python.

[5ubw0r1d]

scalt, on 9 Feb, 2009 - 03:56 PM, said:

As far as comments go, I find the single, most helpful thing any coder can do is put a comment at the beginning of each method/function/class or even large blocks of code explaining what it does. Usually it only takes a sentence or two (anything longer gets pointless) and it makes it so much easier for anyone trying to figure out what you were doing.

Just thought I'd mention that because they never covered it at Uni, they just said 'comment your code'. I would agree that stupid little comments on every second linemake it infinitely harder to understand what the hells going on.

Yeah commenting each function is essential. And should be done by all programmers to ensure they remember to REUSE the functions they create. There are sometimes special doc string comments in languages that help with this, and to create documentation for your code i.e. Javadocs, Phpdocs and Pythons Docstrings, etc

[thepeoplescoder]

Holy shit, I just opened Pandora's Box!

[Gloin]

IrishCereal, on 9 Feb, 2009 - 11:14 PM, said:

I honestly do not understand why people do this:

if (condition)
  {
  statements
  }

I like it better and think it looks a lot nicer like this:

if (condition) {
  statements
}

In my project group of 7 people we were discussing this the other day and there was a unanimous decision that the later was better and it was also said that beginners were more likely to use the first while more experienced programmers usually went towards using the later.

[BigAnt]

When people put Excessive white space and comment separators in the code to separate things, especially when the things are only one line of code like:

dosomething



/*************************************************/


nextthing
nextthing


/************************************************
**/


//the end

[5ubw0r1d]

Gloin, on 9 Feb, 2009 - 04:17 PM, said:

IrishCereal, on 9 Feb, 2009 - 11:14 PM, said:

I honestly do not understand why people do this:

if (condition)
  {
  statements
  }

I like it better and think it looks a lot nicer like this:

if (condition) {
  statements
}

In my project group of 7 people we were discussing this the other day and there was a unanimous decision that the later was better and it was also said that beginners were more likely to use the first while more experienced programmers usually went towards using the later.

Yeah I think the former is easier for beginners to understand as they can see an action (well condition if we're being pedantic about it), and then the consequence as result of this condition. Personally, I feel that this a sensible way to teach beginner programmer, but definately not something I like to see coming from a seasoned programmer.

[mocker]

Logical use of whitespace and indenting.. something I don't see enough. I have slightly different personal preferences for how much whitespace, and where to put the opening bracket then other people, but if you are consistent and for the love of god, indent the inner block, then it's readable all the same.

Also something that's been killing me for the past week and a half... not knowing how to logically seperate a function into component functions. Display syntax should NOT be in your data module. I've been completely rewriting a few thousand lines of code because of this. Especially for web applications.. separate data functions, and presentation. Templates are great! AND KILL WHOEVER MADE CGI.PM POPULAR

Case in point (a simple row in a table):

$html .= Tr(td({-colspan=>'2', -wdith=>'10'},' '),
										td({-class=>$class_value, -bgcolor=>'#'.$endpoint->{'color'}},
								[	   a({-href=>'ep_details2.cgi?dest_id=' . $endpoint->{'dest_id'}}, $display_name),
										$endpoint->{'ip_address'}]),
										td({-class=>$class_value}, a({-class=>($endpoint->{'ping_time'}>$endpoint->{'alarm'})?'small_alert':'small', -href=>'/mrtg/' . $lcase_name . '.html'}, $display_ping)),
										td({-class=>$class_value}, $display_capacity),
										td({-class=>$class_value}, $extra_info)
								) . "\n";

[Amadeus]

In order for me:

1. Horrible variable naming conventions (as noted by baavgai, things like a,b,c)
2. A huge amount of comments on self evident code, with virtually non on complex routines. Put a comment block before the section with an explanation of what is going on, and spare me the //declaration of counter variable bullshit.

I find badly spaced or indented code to be a minor annoyance easily compensated for, but annoying nonetheless.

[KYA]

1. crap variable names
2. uppercase variable names
3.INCONSISTENCY

If you start with

if()
{
}

//DO NOT CHANGE TO 

if() {
}

//MIDWAY! ARGHF

4. inconsistency
5. inconsistency
6. inconsistency

[Tom9729]

* When people who have been programming for more than a year don't understand scope.
* When someone declares and defines a variable on the same line (all the time).
* When people are too lazy to type something like "java 6 arraylist" into Google to find the API docs.

This post has been edited by Tom9729: 09 February 2009 - 08:54 PM

[no2pencil]

Tom9729, on 9 Feb, 2009 - 09:51 PM, said:

* When someone declares and defines a variable on the same line (all the time).

I find this interesting. One of my pet peeves is when a variable is declared in the for loop line.

Which would you prefer?

int i=0;
for(i;i<10;i++) 

or

int i;
for(i=0;i<10;i++)

or

for(int i=0;i<10;i++)