-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I think, aside from the brace positioning, we're going around in circles on things about which we just need to agree to disagree. If you have one developer, and one only, you're most likely to find a unanimous vote for or against names, or braces, or variables - but only "most likely". Things I do today are not what I see in code I wrote 10 years ago - part is experience - part is personal taste. Now we look at not just "more than one" developer, but a world-wide community? OMG if we could only get a unanimous vote for *anything* with diversity like that.
I personally detest "I" for interfaces and "_" for variable prefixes. I'm not fond of "braces should line up" but it's better than seeing "I" in front of every interface. And I really like having "Abstract" ahead of anything... well... abstract. That said, I detest paying so much for gas and dealing with people who have no clue yet claim to be the "expert". Do I buy gas? yes. Do I deal with such people? yes. And I put "I" ahead of interfaces and use "_" as prefixes (for class-level) and my braces line up. Why? Because it works. I've grown very tired of "Impl" suffixes, and if you use "Page" for the interface, and you code only one implementation - what is it? BasePage? No, we went all the way and aren't using "Abstract" to denote an abstract class and BasePage already exists as an Abstract class. How about "DefaultPage"? Ok. Now look at your files: Page, BasePage, and DefaultPage. Without opening up your IDE - - what is what? And now we start adding more and more interfaces/abstract classes/implementations. What is "nice" ends up being an IDE-preferred view of the world. I love Eclipse (as others, I'm sure, love their IDE), but I do *occasionally* look at the JavaDoc even for projects where I'm the only person working on it - even more so for projects I do no development on. You can say "just look at the code - it's open source - that's the beauty of open source". And I'll say "no thank you - I just need clarification on the API". (Then I find out, of course, that since it's "open source" the JavaDoc sucks and I _have_ to look at the source [personal pet peeve about bad/lacking documentation for many projects, not just OS - as noted by many users and acknowledged by many developers], but that's missing the point.)
I'd much rather have my interfaces grouped with my default
implementation (which "Page" and "PageImpl" provides in my lovely IDE),
but when every other file or so is "Impl" this or "Impl" that - *ugh*. I
also like having my API jar'ed up separate from my implementation in
some instances - completely throws my "grouped together" out the window
if I have two separate source paths in "my lovely IDE". We give, we
take, we drive on. I don't think most users care as much about the
class/interface naming conventions as the do about API method naming
("rewind" anyone? - no dig there Howard, just that it's the single most
'misunderstood' method I see on the list). As a developer, I love
knowing that any abstract class starts with "Abstract" - I'm a
key-phrase junkie. "Starts with Abstract - hmmm... might have to
subclass that one" - seems pretty simple to me. "AbstractDieselEngine" -
hmmm... Bet I could subclass that one for a DieselEngine implementation.
No JavaDoc needed, no source code to peruse at my leisure. Does that
mean that I wouldn't work with "Engine" as the abstract, and "DEngine"
as an abstract implementation of "Engine" intended for "Diesel" engines?
Nope. Sure doesn't. Just nicer as a personal - non-IDE view the first
way. And believe it or not, 99% of all developers I know have naming
issues. "I have a class that does this, what should I name it?" It's an
unwritten rule - you design, you code, you test (hopefully) - and you
just run out of names that 1) apply and 2) make sense. But of those 99%,
100% don't really care how long it took me to name files any more than I
care how long it took them. We do our best with what we have, and
grumble about it later.So - +1 to any name you choose - we adapt and grumble about it regardless of what's chosen +1 to any code convention you choose - we adapt and grumble about it regardless of what's chosen - -1 to "but this is best because of my lovely IDE" - give a _real_ answer not an IDE specific answer - -1 to breaking backward compatibility because "we've grown so we know now IPage is annoying where Page is not"
and a resounding +1*** to "document it as a project level developer convention and revisit on the developer list if there are true (not imagined) reasons for changes." Hell, go ahead and document (as Howard has done) "This was a bad idea, but changing it would break compatibility." Nothing wrong with that. And those grumblings in the back with be there regardless.
My .02... .03... $1.50
Patrick Casey wrote: | Howard Lewis Ship <hlship <at> gmail.com> writes: | | |>The distinction, in my mind, is that AbstractEngine is incomplete (it has |>unimplemented abstract methods), while DefaultEngine would be a complete |>implementation that could be used as-is or extended. | | | This is fine until we need a subclass extending AbstractEngine that | still keeps some methods abstract. Then we'll have trouble naming | that subclass because they're abstract too. | | AbstractEngine | AbstractDieselEngine | AbstractTurbineEngine | AbstractPistonEngine | | .... | | At least that's the convention I generally go with. | | | | --------------------------------------------------------------------- | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32)
iD8DBQFCazFNaCoPKRow/gARAjetAJ9C08c+b3gdbv3G34Bu1OHi4CNvFACg03BH 9l5je5nOTUudEkbAHr8JAfU= =OCn9 -----END PGP SIGNATURE-----
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
