David I has a post about Coding Peeves. I agree with most of the ones he posted. Here are a few of mine he missed. If you see yourself here don't take it personally. I know I am opinionated. It is part of what makes me interesting! I imagine that some of my coding habits may annoy others, but they will learn to appreciate them.
1) try except blocks with nothing in the exception handler (or just a comment saying "ignore all exceptions"). For really small blocks (like one or two lines) this is can be tolerated, but is really undesirable. Too many times I see a whole screen full of code and an empty exception block. If they want to ignore a specific class of exceptions then they should only trap and ignore that class, but they should be as specific as possible. It is arrogant of the developer to assume they know of every possible exception that could be raised, and that none of them are important. I don't know how often I am tasked with tracking down some odd behavior only to discover the original programmer ignored the exception because they didn't expect this particular one. That is the thing about exceptions, they aren't always expected!
2) Failure to use classes, functions and procedures. Some programmers believe "code reuse" means copy, paste, modify. Maybe the still think their performance is measured on lines of code.
3) Ignoring compiler hints and warnings. Sure, it still compiles, but they are there for a reason. It is really bad when it has gotten out of hand on a really large project, then even if you want to eliminate the ones in the code you are working on you will have a hard time finding them. I personally have a no hints or warnings policy. If there is one I don't know how to clear then I comment it as such, although I have always discovered how to clear them later.
4) Overly strict adoption of Hungarian or reverse Polish notations. When you have complex objects you are working with these notations just turn your variables into alphabet soup! A name variable is a comment about what it contains. Using a notation that denotes the type is like a comment of "set I to 1" - it is redundant. The compiler knows the type and the IDE will tell you.
For example:
Lets say you have a OracleDataReader that is reading sales data. Now what makes more sense: oraDtaRdrSls or SalesData, let alone which is easier to type or refer to in conversation! Although I will allow that some people do like alphabet soup. Maybe that is what we should call the notation.
Another things to consider is if you later change the types of your variables then you need to rename all your variables. Good thing Delphi 2005 has built in refactoring! Time to give those variables in that code you inherited a meaningful name!
5)The use of single line comment characters over multiple lines. I think this is a favorite of the alphabet soup types who like typing extra meaningless characters. Plus if I need to go edit or add to the comment later then I have to worry about where the line breaks and adding new comment marks on each line.
For example:
// We take the integer variable I
// and set it to the value of 1
// oh, and Hi Mom!
vs.
(* We take the integer variable I
and set it to the value of 1
oh, and Hi Mom! *)
That should do it for now. Hopefully no one gets me started again.
5 comments:
I'm sort of with you on 4. oraDtaRdrSls is a bad name, but SalesData or salesData is just as bad or worse. I am against anything that wouldn't make sense when out of the IDE. And "The compiler understands it" is a bad argument. Also, variable names that look like procedure names are never a good idea.
My reasoning goes as follows: when I'm coding, my hands are on the keyboard and should be able to stay there. I dont want to have to fondle the mouse just to figure out what something is.
So what would I consider to be a cood name for that variable up above: drSalesData. Was that so bad.
Type prefixing is a good think that does help with code readability, but I will fully agree that oraDtRd or oradr goes to far and hinders the readability. Keep the prefix short (3 characters or less).
3) ... I personally have a no hints or warnings policy.
I totally agree with you. But when using Delphi 2005 trial i get the following warning on my project:
"Unsafe typecast of 'Pointer' to 'TObject'"
in a TObjectList.Sort callback method (TListCompare).
Can you then tell me how to prevent this warning from occurring?
And how do i prevent the hint:
"Inline function 'AnsiSameText' has not been expanded because unit 'Windows' is not specified in USES list"
when i do not want to use the Windows unit?
I wasn't able to get the "Inline function" hint. Can you give me some sample code?
I'll have a follow up post on the warnings though.
with the following source (Delphi 2005 Trial: New VCL Forms application - Delphi for Win32)
unit Unit1;
interface
uses
// note: no windows
Classes, Graphics, Controls, Forms, StdCtrls;
type
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
implementation
{$R *.dfm}
uses
SysUtils;
procedure TForm1.Button1Click(Sender: TObject);
begin
if AnsiSameText('foo', 'bar') then
Beep;
end;
end.
the following hint is given when compiling:
Inline function 'AnsiSameText' has not been expanded because unit 'Windows' is not specified in USES list
(sorry for the visual layout of the code)
Since you use SysUtils you are using Windows, so add Windows to your uses clause. I posted a better explination.
Post a Comment