Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


You became a programmer anarchist. What are some conventions that you don't want to follow along?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
27 replies to this topic

#1 tom_mai78101   Members   -  Reputation: 575

Posted 03 October 2012 - 09:41 AM

Conventions are put in place so that others will know what were defined correctly. All is good when one follows the conventions. But what if one doesn't? Surely, if there's a good side, there has to be a bad side.

Seeing a giant switch..case code? Convert them all to if...elsif...else. Or replace all if...else to using a ternary operator.
See a function returning an integer? #define that integer as FUNCTION_RETURNING_VALUE, and set that in place.
See a small method? Add meaningless code that does nothing inside the method, to make it look like it's done professionally. (Works nicely with VS C++ compiler, as they optimize code upon building the codes. All meaningless codes will be erased from build.)
Have a meeting? Be a badass. :D

Defying the conventions sounds fun, but intrusive to the industry. So, the inner child of me have mixed feelings about this.

Sponsor:

#2 slayemin   Members   -  Reputation: 2790

Posted 03 October 2012 - 09:54 AM

When you're working with multiple people on the same code, standardized coding conventions are a good way to boost team productivity.

When you're writing code which needs to be maintained months or years down the road, having a coding standard and consistency is a good thing!

There is a good reason for having and following conventions :) I think coding used to be a rather chaotic discipline and from that chaos, via the forces of evolution, emerged the best conventions and practices we use today. To return to the chaos would seem counter-productive...

Eric Nevala

Indie Developer | Dev blog


#3 Bacterius   Crossbones+   -  Reputation: 9055

Posted 04 October 2012 - 07:27 AM

The bad side of conventions is fanatics following them when they're not appropriate or simply obsolete. Or people arguing over brace style conventions, seriously, just pick one already, rand() % 2 if you need to! (Allman ftw, scraping lines to get more code on the screen is so 20th century, lol)

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#4 Hodgman   Moderators   -  Reputation: 30926

Posted 04 October 2012 - 08:11 AM

I used to work at a place that had extremely strict commenting conventions, where every single function had to be commented with... the name of the function, the date it was added, and the original author... and optionally what it does.
During a crunch period I got sick of it and started writing code like:
/*--------------------------------------
 * Function: DrawShadows
 * Date: 12/34/56
 * Author: Hodgman
 * Comment: This actually erases the save games, it's just really badly named. No, really. don't call this to draw shadows.
 *------------------------------------*/
void DrawShadows()
{
...code to draw shadows...
}


#5 d000hg   Members   -  Reputation: 782

Posted 04 October 2012 - 09:35 AM

If you want to be an anarchist...

Make sure you adhere to no naming convention... use getName(), name(), Name() interchangeably
Use var, mVar, m_var,m_Var and various Hungarian things interchangeably, preferably within the same class
Refuse to use source control
Refuse to wait for code review or testing, throw your changes ad-hoc onto live systems and of course don't document it

#6 Shippou   Members   -  Reputation: 1688

Posted 04 October 2012 - 11:15 AM

I do not follow capitalization conventions in Java.
Any useless variable, that is mandatory to have in code, is named "X" ( Such as in LSL )
Python purists have a fit every time they read my code examples, as I tend to compact code and throw the entire Python Mantra out the window.

 Reactions To Technologies:
1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
3. Anything invented after you're thirty-five is against the natural order of things.

- Douglas Adams 2002


 


#7 way2lazy2care   Members   -  Reputation: 782

Posted 04 October 2012 - 12:37 PM

If you want to be an anarchist...

Make sure you adhere to no naming convention... use getName(), name(), Name() interchangeably
Use var, mVar, m_var,m_Var and various Hungarian things interchangeably, preferably within the same class
Refuse to use source control
Refuse to wait for code review or testing, throw your changes ad-hoc onto live systems and of course don't document it


Don't forget to use different types of white space and following whitespace.

Add comments above, below, before, after, and sometimes in the middle of lines of code, but never following any set standard.

[source lang="csharp"]//Why would someone do this?public void /*because...*/ somefunction(blah blahblah) // fuck you!//... that's why.[/source]

#8 froop   Members   -  Reputation: 636

Posted 04 October 2012 - 12:57 PM

I don't like this
if(..) {
}
I prefer
if(..)
{
}
Looks more structured to me.

I also don't like white space everywhere. Like
if ( bla ) {
 do ( bla );
}

Edited by froop, 04 October 2012 - 01:02 PM.


#9 MichaBen   Members   -  Reputation: 481

Posted 04 October 2012 - 01:19 PM

I also don't like white space everywhere.

if((doSomething(stuff,moreStuff)&&!didSomethingAlready)||(didSomethingAlready&&noNeedToDoMore&&overrideAlreadyDidSomething(manager.name.c_str())))
Yup, much nicer. Seriously, I have seen stuff like this in code. And yet they wondered why so often bugs appear. Being an anarchist and breaking all rules may be fun to do for a bit, trying to get up with a working program that abuses operator overloading like mad and consists of code that when you look at it looks like a pacman made of code and whitespace. But mostly guidelines are there for a reason. Of course, they are guidelines for a reason as well, break them if you have to, but you need to be able to defend your decision to break them.

Edited by MichaBen, 04 October 2012 - 01:23 PM.


#10 brx   Members   -  Reputation: 720

Posted 04 October 2012 - 01:40 PM

I don't like this

if(..) {
}
I prefer
if(..)
{
}

Been there... done it... got used it... makes no difference to me anymore...

I also don't like white space everywhere. Like

if ( bla ) {
do ( bla );
}

Yup, much nicer. [...]

Yes, I do agree, white spaces are YOUR FRIEND! However, liking this (i.e. the stated example
if ( s == o ) {
}
) is just WRONG! (ok, ok, it's all about opinions...) But, this is just something that *every single* coding convention I have ever used with agrees with (including the "official" Java and C# styleguides). The only people (at the place I work) that write like this are mathematicians that should not touch the code. PERIOD!!! (yes, I am getting carries away, but it's the truth!) It's got to look like this:
if (foo == bar) {
	// there's what do do if foo equals bar
}
(and yes, I've seen very f'ed up coding conventions... ;) )


...

And, to stay on topic (although, I don't quite get it)... this is something evil to do:
#define TRUE FALSE //Happy debugging suckers
Some fun (most will already now it, but I like to read it once in a while): http://stackoverflow...ver-encountered


// way too many edits... time to go to bed...

Edited by brx, 04 October 2012 - 02:00 PM.


#11 tstrimple   Prime Members   -  Reputation: 1723

Posted 04 October 2012 - 01:48 PM

I tend to stick with what the majority of people in the language use. That means:

C#
if(true)
{
    // stuff
}

Javascript
if(true) {
    // stuff
}

CSS
.selector {
     /*    style!    */
}


#12 CryoGenesis   Members   -  Reputation: 496

Posted 04 October 2012 - 02:05 PM

Setters and getters. Why, just why?

#13 d000hg   Members   -  Reputation: 782

Posted 04 October 2012 - 02:18 PM

Setters and getters. Why, just why?

Go read a book and find out.

#14 alnite   Crossbones+   -  Reputation: 2123

Posted 04 October 2012 - 02:20 PM

Fucking Hungarian notation will kill me. Fuck that, and fuck that to hell. Underscores are also pain in the ass.
private:
	 int _omg;
	 int __uberomg;

int some_stupid_calculation = __uberomg + _omg * __uberomg / __uberomg + __othervar + __more_private_variable + __underscore;



#15 brx   Members   -  Reputation: 720

Posted 04 October 2012 - 02:21 PM

Setters and getters. Why, just why?

That's easy!
Setters... because they sometimes do good stuff (i.e. bound checks, assertions, etc)!
Getters... because if the setters do good stuff, you just can't make the member public!

Edited by brx, 04 October 2012 - 02:23 PM.


#16 tstrimple   Prime Members   -  Reputation: 1723

Posted 04 October 2012 - 02:28 PM


Setters and getters. Why, just why?

That's easy!
Setters... because they sometimes do good stuff (i.e. bound checks, assertions, etc)!
Getters... because if the setters do good stuff, you just can't make the member public!


Getters are also useful for lazy evaluation / data fetching. In C# you can also change the visibility of getters / setters independently.

public int SomeValue { get; private  set;}

You now have a member property that is read-only outside of the base class.

#17 Nypyren   Crossbones+   -  Reputation: 4495

Posted 04 October 2012 - 02:28 PM

Setters and getters: Because they can be virtual in most languages. In C# they can have public get/protected set (as stated above) and also be specified as part of an interface.

Edited by Nypyren, 04 October 2012 - 02:30 PM.


#18 tstrimple   Prime Members   -  Reputation: 1723

Posted 04 October 2012 - 02:31 PM

Fucking Hungarian notation will kill me. Fuck that, and fuck that to hell. Underscores are also pain in the ass.

private:
	 int _omg;
	 int __uberomg;

int some_stupid_calculation = __uberomg + _omg * __uberomg / __uberomg + __othervar + __more_private_variable + __underscore;


It wouldn't surprise me, but do you really have to deal with multiple levels of underscores? Typically underscores don't bother me, and they provide a nice side effect of showing all private variables in intellisense when you type _. I see them a lot less frequently now that we have auto-implemented getter / setter support in C#.

#19 tstrimple   Prime Members   -  Reputation: 1723

Posted 04 October 2012 - 04:12 PM

Ok, I'll throw this out there. While not a coding convention... I find unit tests to be highly overrated. Their biggest benefit is actually just forcing you to think about how your code is going to be used. From that perspective they are great, but you should be thinking about your code's clients anyway! In the end you have a huge number of tests which is supposed to protect you when refactoring, but chances are if you're doing any significant refactoring chances are you'll have to overhaul your unit tests as well.

Furthermore, unit tests don't prevent the type of errors I encounter most in software projects I'm working on. Integration tests do. Testing how separate systems interact and communicate has been far more valuable to me than unit tests have been.

#20 Bacterius   Crossbones+   -  Reputation: 9055

Posted 04 October 2012 - 11:00 PM


I also don't like white space everywhere.

if((doSomething(stuff,moreStuff)&&!didSomethingAlready)||(didSomethingAlready&&noNeedToDoMore&&overrideAlreadyDidSomething(manager.name.c_str())))
Yup, much nicer. Seriously, I have seen stuff like this in code. And yet they wondered why so often bugs appear. Being an anarchist and breaking all rules may be fun to do for a bit, trying to get up with a working program that abuses operator overloading like mad and consists of code that when you look at it looks like a pacman made of code and whitespace. But mostly guidelines are there for a reason. Of course, they are guidelines for a reason as well, break them if you have to, but you need to be able to defend your decision to break them.

There should be spaces between non-unary operators and after commas, but there should not be a space after an opening bracket nor before a closing one. Just like in typography. The case of wrapping an unary operator like negation between brackets is arguable, it's a common mathematical convention that unary operators take precedence over just about anything else, but this can be violated in programming languages with preprocessor rules, prefix/postfix operators, or other stuff. Thus:
[source lang="cpp"]if ((doSomething(stuff, moreStuff) && (!didSomethingAlready)) || (didSomethingAlready && noNeedToDoMore && overrideAlreadyDidSomething(manager.name.c_str())))[/source]
You can also use newlines to make the || operator terms more visible, or even break the condition into two different conditions based on didSomethingAlready. Or just use shorter function names and less conditions.There is always a solution.

People who put redundant brackets with extra spaces inside them and before semicolons, and deliberately omit spaces around assignment operators drive me insane! I see this kind of code all the time in VB and Java code for some reason:
[source lang="cpp"]if( ( myCondition )==MY_DEFINE ){return ( ~myCondition*2+(1+1) ) ;}[/source]
Posted Image

Edited by Bacterius, 04 October 2012 - 11:01 PM.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS