C#
if(true)
{
// stuff
}
Javascript
if(true) {
// stuff
}
CSS
.selector {
/* style! */
}
You became a programmer anarchist. What are some conventions that you don't want to follow along?
I tend to stick with what the majority of people in the language use. That means:
C#
Javascript
CSS
C#
Javascript
CSS
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;
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!
[quote name='CryoGenesis' timestamp='1349381144' post='4986862']
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!
[/quote]
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.
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.
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#.
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.
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.
[quote name='froop' timestamp='1349377057' post='4986841']
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.
[/quote]
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]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
