I think that while you should be consistent in your code you should understand what possible variations exist? If a operation can be overloaded, or called with empty parens, or with one variable or n variables. If the operation creates a new Object, What is the constructor? If the Object has more than one constructor which constructor is more efficient? This way you can understand other people's code much easier. Being able to understand other people's code is very important because you will no doubt have to read other people's code. When I was taking AI this semester we had to use a set of classes provided by our professor and enhance them for predicate calculus. Unfortunately, his code followed his own random syntax instead of the syntax he had been teaching in lecture and in the book. If you weren't able to understand the code you were basically up a creek. So comprehension is a huge factor as well as being consistant in what you code so that others who have to read large amounts of your code will be able to better understand your code.

Scott

Everyone has their demons....

Well, I don't know about object oriented programming, because I come from procedural programming. Perhaps there are reasons in OO programming to mix up style a bit...but I wouldn't know. But I <emp>am</emp> sure that no matter what kind of programming you are into, comprehension is the foremost factor when considering style (IMHO).

redmist
redmist.dyndns.org
email::redmist

Well I look at programming through math-colored eyes. :-)

Not to disrespect your mother, but an important part of becoming good at math is the realization that notation doesn't matter. (-:Another is realizing that it does.:-) One of the best tricks I have seen for getting people to understand this is doing calculus using drawings of umbrellas and beach-balls for your variables.

The point is that notation may be how we talk about ideas, but it should not be confused with those ideas. Indeed the "big" math discoveries either tend to be new fundamental ideas, or else discovering that here and there, even though they are using different words, they are really talking about the same thing and here is how to unify our understanding of them.

So getting past confusing notation for ideas is key to becoming good at math. And programming as well! For instance on my home node there is a link to a discussion by Linus Torvalds on how to use macros instead of #ifdefs to make portable code easier to maintain. Well Perl doesn't have #ifdef, but if you understand the idea you can see how to create an abstraction layer of functions you call which (behind the scenes of course) will load platform specific behaviour. So even though we don't have the construct Linus talked about, we can separate out the idea he is getting at (how to get all of your portability assumptions into one place) from the notation (#ifdef) and benefit.

The idea is what matters.

OTOH notation also matters. Why? Because in the end you are talking to a human. So while your understanding should not be tied to (or confused with) the notation, you need to know how to say things in a way that others (and you!) will understand. And for that the notation matters a whole lot.

Whew, a bit long but hopefully it will help you clarify your thoughts on the matter.