On the usefulness of Livejournal

[jennyaxe]

Just when I was feeling somewhat ashamed for starting my day at work reading Livejournal, I come across this link on what Hungarian notation should be in bcholmes journal. Since what I'm working on is a bigger project than I'm used to, and one which I'm basically starting from scratch, stuff like that really comes in handy.

I've even dug up one of my old books from when I was at the university learning systems design. It'll come in handy for designing the database. The one I'm replacing was a proof-of-concept thingy, where the logs were just slurped into tables with one column per field and an index on every column. I'm fairly sure I'll be able to do something better than that!

Comments

[jester-uk.livejournal.com]

Hungarian notation should be screwed up and thrown in the trash.
It should then be replaced with sensible variable names, and properly defined data types, coding practices and compilor warnings.

It doesn't work if you're using user defined types anyway, and merely serves to prefix variable names with an ugly looking string of characters which don't tell you anything that looking at the code should already be telling you.

You'll probably find most programmers sit firmly in the for or against camps, so it's not surprisng it got renamed Bosnian notation at a place I was working at in the early 90s.

[jennyaxe.livejournal.com]

Um, did you actually read the text I linked to? Because it was not about using a string of letters to tell if a variable is a string or a char or an array or what have you. That, I entirely agree, is worse than useless.

[bellinghman.livejournal.com]

It's still about sticking the type onto the variable.

Ironically without making use of different types for your actual safety.

If you're worried about accidentally assigning a "user string" to an "internal string", and think that training your brain into be a Perl taint substitute, then you're doing things wrong. If your language has types, then make them different types. And in any case, make the user input safe at the boundary. Don't carry it inside your system. Full stop.

(I've not had the full opportunity to read the entire article. I'll do that later. But it appears to be reiterating the same sad arguments I've seen refuted several times before.)

[jester-uk.livejournal.com]

I've now had a chance to read the bit where he actually explains the differences betwwen Apps Hungarian (which looks vaguely useful, although I still stand by what I said before) and System Hungarian which is the one that I've previously been exposed to.

I still don't think it's the proper solution to the problem.

[bellinghman.livejournal.com]

I'm actually a user of 'hungarian-lite'

In other words, I use some naming convention to distinguish between globals (horror!), locals and members. Oh, and also types. But the purists maintain that any function that doesn't allow you to see the declaration of your variable at a glance is too long.

In other words, more than a screen is too long.

I'll get onto the "Exceptions Bad" part later. Let it suffice for now that the last time I encountered an "Exceptions Bad" article, I wondered how the author actually expected his code to be robust and maintainable.

(Writing good code that copes with exceptions isn't easy. But it's the writing good code part that's the tricky bit.)

[jennyaxe.livejournal.com]

I think that the ideas I got from that article pretty much match your "hungarian Lite". I.e. make sure that the variable names are descriptive, and keep to some standards as to what they should describe. That information need not be in a prefix, but it'd be a good ide to take some extra thought to coding standards before I start coding.