Re: Multiple returns vs. Single exit

Randall R Schulz <[email protected]> Fri, 28 Dec 2007 14:10:07 -0800
Newsgroups gmane.comp.windows.devel.java.advanced
Message-ID <[email protected]>
On Friday 28 December 2007 13:49, Attila Szegedi wrote:
> On 2007.12.28., at 21:47, Mark Gorokhov wrote:
> > ...
> >
> > There is no "either-or" in our coding standards. We must use a
> > single return, no Hungarian notation (but "m_" is mandated), and so
> > on.
>
> Heh - that's already partly Hungarian notation then. Charles probably
> doesn't read this list, so I don't think I'm running the risk of
> scorn next time I bump into him, but Hungarian notation is totally
> meaningless for a reasonably strongly typed language such as Java.

It doesn't add anything for types, but I find it helpful for storage
class (to use a C / C++ term). I use a very few prefixes:

        fFieldName
        cStaticFieldName
        eEnumName

I hate all-caps except for acronyms and initialisms and don't like
underscores, though I'll use the latter when necessary to separate to
adjacent acronyms.

One reason I like the field prefixes is to get me out of
using "this.fieldName" which is something I dislike The f prefix is
less obtrusive and equally informative.

I'll also use iIterationVariable in many of my loops.

Generally speaking, I am minimalist about punctuation (very few curly
braces not required to get the proper parse, e.g.) but elaborate about
layout (lots of columnar formatting, e.g.).

Then there's that idiotic "getAttribute()" / "setAttribute(...)"
convention. Overloading handles this distinction just fine, so
the "get" and "set" prefixes are just noise.

I think my code is pretty and accessible, but most programmers react
negatively to it. IDEA often works against me (especially the absence
of get / set and the columnar formatting, which it eradicates at every
opportunity!)


> ...
>
> Attila.


Randall Schulz

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com