|
Or specifying a value for TOP. But only as necessary.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
6.1 - I had to work on code today of a developer that left us last year. He used concatenated SQL statements... 
This is where something like Entity Framework comes in handy - let it handle your sql inserts / updates.
There was also a whole lot of other bad coding habits. I blame the university where he studied though, seems like they didn't teach him good coding standards.
|
|
|
|
|
Jacquers wrote: university [...] didn't teach him good coding standards
Coding standards? At university? 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
0) 
3) This can be a project killer, good observation.
4) There is no excuse nowadays, there are plenty of tools available to help with refactoring.
5) 
6.1) Unforgivable!
Good observations!
|
|
|
|
|
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.
|
|
|
|
|
Quote: 9) Swallowing Exceptions
My number 1 pet hate. Should be in capitals.
//BUT THAT IS SOMETHING ELSE THAT'S ANNOYING IN COMMENTS
Plz 4giv me shtng
|
|
|
|
|
If you need comments to explain what the code does, then the code is too complex. Formatting is a matter of taste, and there's a keyboard shortcut to automatically reformat in the VS-IDE.
My worst programming habits;
- Removing the access modifier "private" from code, as it is redundant. Not a bad habit in my book, but apparently in everyone else's.
- Hitting F5 too regularly. Kills productivity if it takes 15 minutes to build.
- Reading CodeProject while building a solution. I cannot stare at the build-screen, especially since it does not provide adequate feedback on what it is doing. If it appears to be waiting for a long time then chances are that it gets killed using the task-manager.
- Coffee. With two suger, and two cups an hour, that adds to 32 lumps of suger.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Removing the access modifier "private" from code
There should be no default access modifiers; the developer's intent should be clearly specified. I don't want to have to guess, and you don't want me to keep asking you. Specify it, and decrease the hit to your own productivity caused by your juniors.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
PIEBALDconsult wrote: the developer's intent should be clearly specified.
It IS clearly specified if it is omitted. It is not some arcane trick, it is not something that causes side-effects, and it improves readability. It is as usefull as typing "begin" and "end" instead of the default scope-blocks. It might take some getting used to, but it conveys the same amount of information using less symbols.
That's kinda essential, and the reason why we are not programming in COBOL.
PIEBALDconsult wrote: I don't want to have to guess
If you have to guess at the default access modifier in C#, you should not be writing in C#.
PIEBALDconsult wrote: and decrease the hit to your own productivity caused by your juniors.
Should I prefix each class with a complete namespace? Otherwise they'd be guessing at which class it will take
You explain a junior ONCE that everything that does not have a modifier is private. If they come asking, even once, then make them prefix everything. Using "this" and "that", using namespaces, using "global::". Throw in some hungarian systems, so they won't have to guess the type
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Should I prefix each class with a complete namespace? Otherwise they'd be guessing at which class it will take
You've done it now
|
|
|
|
|
Adding oil to the fire, a practical example;
using System;
using System.Threading;
using System.Windows.Forms;
using System.Timers;
namespace ConsoleApplication5
{
class Program
{
Timer t = new System.Threading.Timer(null);
Timer t2 = new System.Windows.Forms.Timer();
Timer pfld_SysTimrTimrt3 = new System.Timers.Timer();
static void Main(global::System.String[][] strSrgs)
{
global::System.Console.ReadLine();
}
}
}And yes, the "console application template" has an entry point which is implicitly private.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Soooo... the class is private?  How does that work?
Even I avoid global:: -- by using an alias if necessary:
using MySqlClient=global::MySql.Data.MySqlClient ;
What the heck is a pfld_ ? A pointer to a fixed long double?
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
pfld_ is a pointer to a fixed long double and it ranks under other variables in testing.
Hence, the underscore notation.
|
|
|
|
|
PIEBALDconsult wrote: the class is private? How does that work?
Create a new console-application. Look at the access modifier for "Program" and it's entrypoint. Both are private.
Surprised? 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
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 ConsoleApplication1
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
PIEBALDconsult wrote: No; the class is internal.
Yes, have just been reminded (a few posts below) that classes are internal by default, only members are private.
..which does obvious make a bit more sense.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Needs comments as it's not clear whatr t, t2 and pfld_SysTimrTimrt3 are
PooperPig - Coming Soon
|
|
|
|
|
Eddy Vluggen wrote: explain a junior ONCE
That's once too many.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
"this" was introduced for a reason and should be used.
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
class uhoh
{
bool yay;
uhoh(bool yay)
{
this.yay = yay;
}
}
... is usually the only time I want to use "this".
Unless there was another "uhoh" being involved in an uhoh function. Which is probably not good practice.
|
|
|
|
|
Can you explain the reason? 
There is no good argumentation. "This" is used for the nut-cases who don't want to prefix with an underscore, and it is one of the most abused keywords, littering code without adding ANY value whatsoever.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: prefix with an underscore
 Yuck, filth, "littering code without adding ANY value whatsoever".
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
PIEBALDconsult wrote:
Yuck, filth, "littering code without adding ANY value whatsoever".
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;
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;
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;
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
If you can't read my code, try converting it here[^]
|
|
|
|
|
Better auto complete systems don't need this. as a crutch to figure out what they should be offering as suggestions. It may have been useful a decade ago but belongs on the rubbish heap today.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Eddy Vluggen wrote: Should I prefix each class with a complete namespace
Maybe not each, but I've found that some namespaces use way too simple names to be safe to use without! E. g. in C++ I never use using namespace std, since it clutters the global namespace with many symbols that are common enough that they may clash with just about every nontrivial application code.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
