What are the worst programming habits?
-
// check if user is valid
if(IsUserValid(user))
{
// update the user
UpdateUser(user);
}
else
{
// show a messagebox with an error
MessageBox(error);
}Worthless comments, agreed...but doesn't mean comments aren't expected. I'd much rather have a comment at the beginning of the code segment saying what this chunk of work means, rather than what each step does...for example:
// better validate user before we get too far into the process...
</twocentsworth>
I used to call it "Super Happy No-Pants Wonder Day"! It turns out that the police just call it "Tuesday". Go figure...
Normally happens if you write the comments before you write the code. It is just forgetting to remove the obvious comments after the code has been written.
-
I've encountered a similar, but annoying variant of this. There were a whole bunch of functions in my old employer's code base which did nothing but call an almost identically named function, such as:
someFunc(int a, string b)
{
return some_Func(a, b);
}In some cases, this went on for a step or two further, with some_Func calling some__Func (I HATE double underscores in code), which then again finally called the 'real' function someOtherFunc. I suppose it was the result of a messed up attempt at refactoring. It was hugely annoying when debugging.
Spoon Of Doom wrote:
nothing but call an almost identically named function
I've seen that too. It was in just plain C, in some code that represented a layered architecture -- so it was similar to:
BL_GetDate() { return DAL_GetDate() ; }
An OOP version might be:F() { base.F() ; }
:sigh:You'll never get very far if all you do is follow instructions.
-
Then please show me the way parametrizing a table name, or field names in a query. Of course, you can keep hacking[^].
Or specifying a value for
TOP
. But only as necessary.You'll never get very far if all you do is follow instructions.
-
I hope it wasn't provably unreachable, that would have bad implications for the fabric of reality.
I picture things like
if ( name.Length < 0 ) ...
You'll never get very far if all you do is follow instructions.
-
Eddy Vluggen wrote:
Both are private
No; the class is
internal
. Trying to make it private yields: Error 1 Elements defined in a namespace cannot be explicitly declared as private, protected, or protected internal F:\Projects\ConsoleApplication1\Program.cs 9 17 ConsoleApplication1You'll never get very far if all you do is follow instructions.
-
Eddy Vluggen wrote:
Both are private
No; the class is
internal
. Trying to make it private yields: Error 1 Elements defined in a namespace cannot be explicitly declared as private, protected, or protected internal F:\Projects\ConsoleApplication1\Program.cs 9 17 ConsoleApplication1You'll never get very far if all you do is follow instructions.
-
In order of how I have them listed below: 0) Use of VB. 1) Use of Convert and/or ToString rather than casting and/or Parsing. 2) Over-use of Reflection. Not caching and reusing information retrieved via Reflection. 3) Over-reliance on tools, especially third-party tools. 4) Monolithic classes, lack of modularity, non-single-responsibility. 5) Singletons. X| 6) Convoluted concatenation -- a String.Format will be clearer. 6.1) Concatenated SQL statements, when a parameterized statement is better on so many levels. 7) Not leveraging interfaces. 8) Not allowing polymorphism for no apparent reason. 9) Swallowing Exceptions. 10) Posting snippets of code that use uncommon, custon, or third-party classes and expecting everyone to know what they are.
You'll never get very far if all you do is follow instructions.
I like this list.. more to add: 1. Making all member variables public (usually in the context of unit testing.. but also to increase coupling because the original OO design wasn't decomposed correctly) 2. Making all member methods public 3. lack of use of auto_ptr and other more modern mechanisms for properly handling pointer lifetime management. 4. lack of understanding of exceptions, especially their side effects on locking and memory management. (years of my life has been spent on fixing these types of issues..) 5. misunderstanding by value semantics when passing instances of classes across method interfaces. 6. passing container instances by value (eek!). Note these are ALL things I've directly observed/fixed.
-
Eddy Vluggen wrote:
prefix with an underscore
X| Yuck, filth, "littering code without adding ANY value whatsoever". X|
You'll never get very far if all you do is follow instructions.
PIEBALDconsult wrote:
X| Yuck, filth, "littering code without adding ANY value whatsoever". X|
:) There's also a link somewhere in these posts to an article from Joel Spolsky. There have been various ways of indicating that something is a member, as opposed to a local variable. How do YOU differentiate between the two?
class X
{
private int i;
public int I { get { return i; }
public X(int someI)
{
this.i = someI;// further down the road int i = I;
}
}Looks better than prefixing the stuff, but there's hardly any hint that it is a private member or a local variable. It is obvious that I must be something public, either a field or a property. It'd also cause trouble with translating to VB. A simple workaround is using
this
to indicate the member;class X
{
private int i;
public int I { get { return this.i; }
public X(int someI)
{
this.i = someI;// further down the road int i = I;
}
}The prefix is merely there to indicate that it is a member that is being referenced. I'd be writing the same as below;;
class X
{
int _i;
public int I { get { return _i; }
public X(int someI)
{
_i = someI;// further down the road int i = I;
}
}No confusion, and the minimal amount of symbols to convey all the information I want; everything private is recognizable by the underscore, everything public starts with a capital (similar as the recommendations) and everything local start with a non-capital. The value that it adds is that it makes the naming predictable and consistent, makes it easier to spot errors and read the code. It is something that I found that does not cost time, but saves me time.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
I like to be explicit in my code. There is no doubt in my intent. I just find it a bit strange that "private" is the only exception to access modifiers where you have to be explicit about everything but only because it's default. I'm just saying that the access modifier shouldn't have a default forcing you to be explicit in your intent and (granted hopefully) think about what you're doing. I am happy to say, as the other replier pointed out, that I'm not one of those that needs to be "saved from himself" because VB made everything Public by default and that's what generates tons and tons of bad "public everything" code. I don't believe that the problem is with VB. I believe the problem is with the education and the lax standards of what should be taught in school. I've has more than few degreed grads that couldn't tell me the difference between public and private. I've also heard most of those same grads say they've never written an API, to which I call BULLSHIT since every application contains it's own API, usually for the sole consumer being the application itself. I think the entire "private as default" or whatever modifier is default is a Band-Aid on a bigger problem. EDIT: And just for the record, I'm going to admit to being a hypocrite. I also rely on private being the default in my own code but, just because I do it, that in no way means I think it's a good idea.
A guide to posting questions on CodeProject
How to debug small programs
Dave KreskowiakDave Kreskowiak wrote:
I think the entire "private as default" or whatever modifier is default is a Band-Aid on a bigger problem.
With the argumentation that one needs to save the developer from himself. I'm sorry, but that only flies if you don't have any using-clause in your files. Be explicit in the class that you use, or accept the default behaviour.
Dave Kreskowiak wrote:
I don't believe that the problem is with VB. I
Not? You just explained why it is :)
Dave Kreskowiak wrote:
I've has more than few degreed grads that couldn't tell me the difference between public and private. I've also heard most of those same grads say they've never written an API, to which I call bullsh*t since every application contains it's own API, usually for the sole consumer being the application itself.
Knowing the difference between the access-modifiers would be kinda basic knowledge. And no, unless it is intended to be consumed by the public, it is not a public API. If there's no SDK to download, then you're not building a framework.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
I was thinking about the things that bug me and came up with a short list
- No comments. I know - let's have a religious war etc, but I find no comments dangerous.
- using o as a variable name. In fact using anything that's not sensible.
ctx
,dr_rfp_ptr
,i2
- Bad formatting. It's like walking into a house and being unable to sit down because of empty pizza boxes on the couch
- Mystery side-effects in code.
- Magic numbers
I'm guilty of 2 of these on occasion. What's your list?
cheers Chris Maunder
Chris Maunder wrote:
What's your list?
1. Building something because the developer wants it rather than because a customer wants it. 2. Assuming that because something is new that it better. 3. Assuming that because something is new is it without fault and requires no time learn to use well.
-
I was thinking about the things that bug me and came up with a short list
- No comments. I know - let's have a religious war etc, but I find no comments dangerous.
- using o as a variable name. In fact using anything that's not sensible.
ctx
,dr_rfp_ptr
,i2
- Bad formatting. It's like walking into a house and being unable to sit down because of empty pizza boxes on the couch
- Mystery side-effects in code.
- Magic numbers
I'm guilty of 2 of these on occasion. What's your list?
cheers Chris Maunder
I think i'm guilty of the first one, although I usually only comment when it's not clear what the code does or it may have some unintended side effects.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
I was thinking about the things that bug me and came up with a short list
- No comments. I know - let's have a religious war etc, but I find no comments dangerous.
- using o as a variable name. In fact using anything that's not sensible.
ctx
,dr_rfp_ptr
,i2
- Bad formatting. It's like walking into a house and being unable to sit down because of empty pizza boxes on the couch
- Mystery side-effects in code.
- Magic numbers
I'm guilty of 2 of these on occasion. What's your list?
cheers Chris Maunder
-
In order of how I have them listed below: 0) Use of VB. 1) Use of Convert and/or ToString rather than casting and/or Parsing. 2) Over-use of Reflection. Not caching and reusing information retrieved via Reflection. 3) Over-reliance on tools, especially third-party tools. 4) Monolithic classes, lack of modularity, non-single-responsibility. 5) Singletons. X| 6) Convoluted concatenation -- a String.Format will be clearer. 6.1) Concatenated SQL statements, when a parameterized statement is better on so many levels. 7) Not leveraging interfaces. 8) Not allowing polymorphism for no apparent reason. 9) Swallowing Exceptions. 10) Posting snippets of code that use uncommon, custon, or third-party classes and expecting everyone to know what they are.
You'll never get very far if all you do is follow instructions.
-
I was thinking about the things that bug me and came up with a short list
- No comments. I know - let's have a religious war etc, but I find no comments dangerous.
- using o as a variable name. In fact using anything that's not sensible.
ctx
,dr_rfp_ptr
,i2
- Bad formatting. It's like walking into a house and being unable to sit down because of empty pizza boxes on the couch
- Mystery side-effects in code.
- Magic numbers
I'm guilty of 2 of these on occasion. What's your list?
cheers Chris Maunder
ctx - it is assumed that it should point to some context structure, it is(should; may) not variable in usual sense but rather - the function parameter so it may be "pure functional".
-
I was thinking about the things that bug me and came up with a short list
- No comments. I know - let's have a religious war etc, but I find no comments dangerous.
- using o as a variable name. In fact using anything that's not sensible.
ctx
,dr_rfp_ptr
,i2
- Bad formatting. It's like walking into a house and being unable to sit down because of empty pizza boxes on the couch
- Mystery side-effects in code.
- Magic numbers
I'm guilty of 2 of these on occasion. What's your list?
cheers Chris Maunder
I have nothing to say against use of comments. They may not be necessary for some, but usually do no harm to anyone. I believe programmers are free to choose any name for a variable so long as they communicate well to people you work with. Using "o" is fine. If it's a problem, change your font. Bad formatting used to a bad practice, but nowadays, we have apps and services to make them neat.
-
How about the SingleOrDefault on the same machine?
Wrong is evil and must be defeated. - Jeff Ello[^]
-
I'm not sure what you mean - the timings were all on the same machine.
PooperPig - Coming Soon
I was just curious on the performance of SingleOrDefault vs FirstOrDefault as per Petes suggestion.
Wrong is evil and must be defeated. - Jeff Ello[^]
-
I was just curious on the performance of SingleOrDefault vs FirstOrDefault as per Petes suggestion.
Wrong is evil and must be defeated. - Jeff Ello[^]
Oh - I see. I didn't do that - the figures were from a test I did some time ago when someone kept going through our code base changing all the .where(predicate).something() to .something(predicate) because they said it was more efficient - which I didn't think was the case.
PooperPig - Coming Soon
-
6. Leaving commented-out code hanging around too long I'm guilty of that one quite often.
The difficult we do right away... ...the impossible takes slightly longer.
-
I was thinking about the things that bug me and came up with a short list
- No comments. I know - let's have a religious war etc, but I find no comments dangerous.
- using o as a variable name. In fact using anything that's not sensible.
ctx
,dr_rfp_ptr
,i2
- Bad formatting. It's like walking into a house and being unable to sit down because of empty pizza boxes on the couch
- Mystery side-effects in code.
- Magic numbers
I'm guilty of 2 of these on occasion. What's your list?
cheers Chris Maunder
Thanks for this week's survey - it's great! :thumbsup: /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com