I want to stab somone... hungarian notation...
-
I have been looking at a Gem in our system because it, like some other compoenents, had to be augmented to work with a nifty new system...
Well this is in source control. Commented code all over the place. Debug statements not in a log.isDebugEnabled block and spread randomly accross multiple lines.
Comments are
not helpfulmissleading.All variables declared on the top of the method (annoying since I havent seen that done in a Java program... ever)
Stupid hungarian notation to a point where I have no idea what the variable intention is. At least it still has an descriptive name-ish... Except for nVectItem... Great now I know its a number and it came from a vector... now WTF is it damnit.
Ok sorry I was ready to stab someone so I had to vent a bit...
-
Also the person was using Log4j and has no concept of the fact that Log4j already puts your class name into the log file based on the configuration... After some code cleaning its half readable :)
-
@dlikhten said:
Debug statements not in a log.isDebugEnabled block and spread randomly accross multiple lines.
Eww, I think I just threw up a little in my mouth.
I'm familiar with this debugging style from group projects at uni, but I think I've gotten a bit too comfortable using ruby and having nice tools like filters and monkeypatching to put debugging in without disrupting the actual app code. So many bad memories just came back.
Oh, and I can sympathise about the hungarian notation too, at least with the way it's generally used. I think if I was rich and never had to work again, I'd spend a reasonable chunk of time finding anyone who'd promoted Systems Hungarian instead of Apps Hungarian and kicking their teeth in.
-
@dlikhten said:
All variables declared on the top of the method (annoying since I havent seen that done in a Java program... ever)
Note that he could be a veteran of C89, which required this.
-
As a Hungarian I actually feel quite offended about the fact that Charles Simonyi is counted as a Hungarian when it comes to giving a name to everybody's favourite naming convention so that the rage of the programmers of the rest of the world is directed to us but he is counted as an American when people are making statistics about individuals who have been in space by nationality so he can't be a subject of national pride.
On the other hand, the Americans have an astronaut (space tourist, whatever) but there isn't any American Notation. Unfair.
:(
-
@aquanight said:
@dlikhten said:
All variables declared on the top of the method (annoying since I havent seen that done in a Java program... ever)
Note that he could be a veteran of C89, which required this.
If I rembember correctly, even Pascal required that. I am not sure about Delphi though, I never had to use that fortunately.
-
@DrJokepu said:
@aquanight said:
@dlikhten said:
All variables declared on the top of the method (annoying since I havent seen that done in a Java program... ever)
Note that he could be a veteran of C89, which required this.
If I rembember correctly, even Pascal required that. I am not sure about Delphi though, I never had to use that fortunately.
What the hell? I do this all the time. Declaring variables all over a function is messy.
-
@morbiuswilters said:
What the hell? I do this all the time. Declaring variables all over a function is messy.
I think if there are two variables of the same size in the same function but declared in different scope (like one in the true and the other in the false (else) branch of an 'if' statement), a smart enough compiler might save some space by not allocating space for both of them on the stack. I am not sure if this is done by any compiler in the real world though.
-
@morbiuswilters said:
What the hell? I do this all the time. Declaring variables all over a function is messy.
Really? What I usually hear is "Declare as close to the usage as reasonable". A big block of names at the start of the function isn't going to tell me much about how these are used or where they are used. A declaration right next to where it starts being used gives context to both the declaration and the usage. Of course, a note after the area it is used in describing if/where you intend to use it again later is nice too. Or make smaller functions.
-
I think if there are two variables of the same size in the same function but declared in different scope (like one in the true and the other in the false (else) branch of an 'if' statement), a smart enough compiler might save some space by not allocating space for both of them on the stack. I am not sure if this is done by any compiler in the real world though.
I think this is done fairly often. The Texas Instruments compiler I use at work does this often even when the variables are declared in the same scope. Because the CPU has plenty of registers, most variables never go into the stack. This makes debugging an interesting experience, since the variables can jump from a register to another or even disappear without warning and the debugger mostly can't keep up.
-
@DrJokepu said:
If I rembember correctly, even Pascal required that. I am not sure about Delphi though
Same syntax as in Pascal:
procedure XYZ; var x: Integer; begin ... end;
@DrJokepu said:
I never had to use that fortunately.
I've heard bad things about the versions after Delphi 7, but Delphi 7 was definitely a great tool!
-
@Lexarius said:
@morbiuswilters said:
What the hell? I do this all the time. Declaring variables all over a function is messy.
Really? What I usually hear is "Declare as close to the usage as reasonable". A big block of names at the start of the function isn't going to tell me much about how these are used or where they are used. A declaration right next to where it starts being used gives context to both the declaration and the usage. Of course, a note after the area it is used in describing if/where you intend to use it again later is nice too. Or make smaller functions.
IMO a matter of habits. In a perfect world, your methods are small and clear, so there is no difference between "at the start of the function" and "close to the usage".
-
@DrJokepu said:
On the other hand, the Americans have an astronaut (space tourist, whatever) but there isn't any American Notation. Unfair.
Of COURSE there is American Notation!
"Declare `em all and let the maintainance programmer sort em out!"
Right?
-
@dlikhten said:
Debug statements not in a log.isDebugEnabled block and spread randomly accross multiple lines.
...
log4j
Doesn't log4j provide you with a Debug method, preventing you from needing to check on your own if debugging is enabled?
-
@aquanight said:
Note that he could be a veteran of C89, which required this.
No it didn't. It just required that variables were declared at the top of a block/compound statement. Whether that matches the whole function body depends on what the natural scope of the variable is.
-
@morbiuswilters said:
@DrJokepu said:
@aquanight said:
@dlikhten said:
All variables declared on the top of the method (annoying since I havent seen that done in a Java program... ever)
Note that he could be a veteran of C89, which required this.
If I rembember correctly, even Pascal required that. I am not sure about Delphi though, I never had to use that fortunately.
What the hell? I do this all the time. Declaring variables all over a function is messy.
When you declare variables inline its very easy to see what the variable type is. Especially if the variable is short-lived in a block. However hungarian notation is good if you are using NOTEPAD (one of my co-workers uses NortonCommander) and its good for figuring out the type, but with modern IDEs (anything that came after VIM) you can mouse-over a var (or something similar) and see it's type. Its useful in PLSQL still since there is no amazingly good editor for PLSQL, but outside of that its not even standardized, its just whatever sounds right in their mind. So is it l for List or a for Array or v for Vector? Which notation to use? Who knows, who cares.
-
@vt_mruhlin said:
@dlikhten said:
Debug statements not in a log.isDebugEnabled block and spread randomly accross multiple lines.
...
log4j
Doesn't log4j provide you with a Debug method, preventing you from needing to check on your own if debugging is enabled?
Yes and no.
log.debug will print only if debugging is enabled... But if you do this:
log.debug("Debug statement for user: " + name + " with permissions " + permissions);
This is a computationaly bad statement. Create a string builder and concat 4 strings. Name is a string, permissions is a List that gets converted to a string. Instead we do
if(log.isDebugEnabled()){
<whatever crazy debug logic you want, inclduing functiona calls, loops, Evil Sort algorithms, etc..., which will never execute if debug is disabled...>
}
Ok I suck at explaining: log.debug ensures nothing is printed, but concats and loops or w/e is needed for debug still gets executed. By doing a simple boolean variable check you avoid all that computation overhead, including most likely string concats.
-
@ammoQ said:
IMO a matter of habits. In a perfect world, your methods are small and clear, so there is no difference between "at the start of the function" and "close to the usage".
Agreed. I try to follow the "start of function" rule even with languages like Javascript and perl. I think of it like getting a cast of characters before reading a play. Most OO languages make you declare instance variables at the top of the class definition and it seems to greatly improve the readability of the code.
-
@dlikhten said:
When you declare variables inline its very easy to see what the variable type is. Especially if the variable is short-lived in a block. However hungarian notation is good if you are using NOTEPAD (one of my co-workers uses NortonCommander) and its good for figuring out the type, but with modern IDEs (anything that came after VIM) you can mouse-over a var (or something similar) and see it's type. Its useful in PLSQL still since there is no amazingly good editor for PLSQL, but outside of that its not even standardized, its just whatever sounds right in their mind. So is it l for List or a for Array or v for Vector? Which notation to use? Who knows, who cares.
Wat? You contradict yourself almost immediately. If IDEs do all the heavy lifting for you, why do you need the variable declared close to use? Hungarian is just junk, anyway. I use vim and have no problem figuring out types -- it's pretty easy given a tiny bit of context. The exception is gnarly C++ because operator overloading can really confuse the situation, but it's similarly hard for IDEs to untangle C++. Still, if you can't figure out the type of a variable from its usage, it would seem you have some very difficult to read code.
-
@morbiuswilters said:
What the hell? I do this all the time. Declaring variables all over a function is messy.
Agreed. My IDE helps if I need to remember where it was declared or (heaven forbid) I can't tell from the name or context what type it is.
-
@tdittmar said:
I've heard bad things about the versions after Delphi 7, but Delphi 7 was definitely a great tool!
You're right about Delphi 7, and what you've heard about later versions is wrong. <g> 2007 is a great version of Delphi, and they finally ironed out the majority of the bugs in the totally new IDE introduced with (IIRC) Delphi 2005.
-
@morbiuswilters said:
The exception is gnarly C++
Ugh! Who did you piss off that's punishing you by making you work in C++?
-
@morbiuswilters said:
Wat? You contradict yourself almost immediately. If IDEs do all the heavy lifting for you, why do you need the variable declared close to use? Hungarian is just junk, anyway. I use vim and have no problem figuring out types -- it's pretty easy given a tiny bit of context. The exception is gnarly C++ because operator overloading can really confuse the situation, but it's similarly hard for IDEs to untangle C++. Still, if you can't figure out the type of a variable from its usage, it would seem you have some very difficult to read code.
Sounds wierd but its not a contradiction...
If you have a small code block, having the following
if(blablabla){
String x = doSomeWorkAndGetAString();
process(x);
}
Its easy for your eye to see it. You can let the compiler figure out that the memory for x could be allocated once for the function, or maybe even once for the class...
However my point was: IDEs (and I mean anything > notepad or pico) remove the need for hungarian notation. If the variable is far away, you don't need the iVarName to know that the variable is an Integer.
HOWEVER inline declarations are still easier on the eye as it lets you skim the code without having to remember much. The less memory that is required by your brain to follow a function, the quicker you can follow it.
To follow a function with var decs on top, you must remember all of that or mouse-over to get the declaration, which makes you have to remember it. If its right there there is a smaller memory requirement and thus more productivity from YOU. The computer does not care, the compiler can optimize and standardize (If your language requires under the hood to have all decs on the top of the function, then why not, let the compiler do it for you) In fact if you look at Flex 2, under the hood ALL variables must be declared at the begining of the method, but the compiler is really nice and lets you do inline declarations, and if you do two inline decs in the same method for the same var name in diff scopes it will give you a warning.. But will still compile and be nice to you.
-
@ammoQ said:
IMO a matter of habits. In a perfect world, your methods are small and clear, so there is no difference between "at the start of the function" and "close to the usage".
I'd say declare them close to the usage if it's a strongly-typed language or if it has a default value. That makes it a little easier to spot how the variable is used.
-
@Cap'n Steve said:
I'd say declare them close to the usage if it's a strongly-typed language or if it has a default value. That makes it a little easier to spot how the variable is used.
Probably doesn't matter that much. Consider the following case:
someType v = null; // (1)
...
v = getFoo(); // (2)
...
doSomething(v); // (3)
The IDE is able to tell you that v is a "someType", so (1) isn't really interesting. Things get interesting when you examine (3). Where does v come from? You have to be able to spot the corresponding (2). Of course there can be more than one assignments to v, in different if cases etc. But to do that, it doesn't matter where (1) is.
