84 Replies - 14639 Views - Last Post: 23 October 2012 - 07:36 AM
#16
Re: OPC (Other People's Code)
Posted 09 February 2009 - 04:50 PM
#17
Re: OPC (Other People's Code)
Posted 09 February 2009 - 04:54 PM
IrishCereal, on 9 Feb, 2009 - 03:14 PM, said:
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

#18
Re: OPC (Other People's Code)
Posted 09 February 2009 - 04:55 PM
IrishCereal, on 9 Feb, 2009 - 03:14 PM, said:
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
#19
Re: OPC (Other People's Code)
Posted 09 February 2009 - 04:56 PM
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
#20
Re: OPC (Other People's Code)
Posted 09 February 2009 - 04:58 PM
Gloin, on 9 Feb, 2009 - 03:29 PM, said:
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.
#21
Re: OPC (Other People's Code)
Posted 09 February 2009 - 05:00 PM
scalt, on 9 Feb, 2009 - 03:56 PM, said:
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
#22
Re: OPC (Other People's Code)
Posted 09 February 2009 - 05:04 PM
#23
Re: OPC (Other People's Code)
Posted 09 February 2009 - 05:17 PM
IrishCereal, on 9 Feb, 2009 - 11:14 PM, said:
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.
#24
Re: OPC (Other People's Code)
Posted 09 February 2009 - 05:17 PM
dosomething /*************************************************/ nextthing nextthing /************************************************ **/ //the end
#25
Re: OPC (Other People's Code)
Posted 09 February 2009 - 05:24 PM
Gloin, on 9 Feb, 2009 - 04:17 PM, said:
IrishCereal, on 9 Feb, 2009 - 11:14 PM, said:
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.
#26
Re: OPC (Other People's Code)
Posted 09 February 2009 - 05:32 PM
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";
#27
Re: OPC (Other People's Code)
Posted 09 February 2009 - 05:52 PM
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.
#28
Re: OPC (Other People's Code)
Posted 09 February 2009 - 05:55 PM
2. uppercase variable names
3.INCONSISTENCY
If you start with
if() { } //DO NOT CHANGE TO if() { } //MIDWAY! ARGHF
4. inconsistency
5. inconsistency
6. inconsistency
#29
Re: OPC (Other People's Code)
Posted 09 February 2009 - 08:51 PM
* 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
#30
Re: OPC (Other People's Code)
Posted 09 February 2009 - 09:08 PM
Tom9729, on 9 Feb, 2009 - 09:51 PM, said:
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++)