On 04/11/2011 09:58 PM, spir wrote:
> I'm reading (just for interest) the LLVM Coding Standards at
> http://llvm.org/docs/CodingStandards.html. Find them very interesting because
> their purposes are clearly explained. Below sample.

I also love their note about naming:

====================================
Name Types, Functions, Variables, and Enumerators Properly

Poorly-chosen names can mislead the reader and cause bugs. We cannot stress enough how important it is to use descriptive names. Pick names that match the semantics and role of the underlying entities, within reason. Avoid abbreviations unless they are well known. After picking a good name, make sure to use consistent capitalization for the name, as inconsistency requires clients to either memorize the APIs or to look it up to find the exact spelling.
====================================

Dunno who the author is, anyway this text is great. I even appreciate points I totally disagree with, because their *purpose* is properly xplained & argumented: thus, discussion can nicely follow on good bases. It looks like if one can logically show them where & why they are wrong, they will actually change their mind (a rare event in disussions among programmers, esp. about coding guidelines ;-).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

"spir" <denis.spir@gmail.com> wrote in message news:mailman.3428.1302601845.4748.digitalmars-d@puremagic.com...
> On 04/11/2011 09:58 PM, spir wrote:
>> I'm reading (just for interest) the LLVM Coding Standards at
>> http://llvm.org/docs/CodingStandards.html. Find them very interesting
>> because
>> their purposes are clearly explained. Below sample.
>
> I also love their note about naming:
>
> ====================================
> Name Types, Functions, Variables, and Enumerators Properly
>
> Poorly-chosen names can mislead the reader and cause bugs. We cannot
> stress enough how important it is to use descriptive names. Pick names
> that match the semantics and role of the underlying entities, within
> reason. Avoid abbreviations unless they are well known. After picking a
> good name, make sure to use consistent capitalization for the name, as
> inconsistency requires clients to either memorize the APIs or to look it
> up to find the exact spelling.
> ====================================
>

I might have mentioned this before, but there was one company I used to work for that regularly had index/counter variables with names like "aaa", "bbb" and "ccc", and I even found a data-loading function named "save". That confused the crap out of me for a quite a while. I don't think I'll ever forget that. There were sooo many other code WTFs there too. Perhaps unsurprisingly, it was a VB house.

Hi,

about early breaks/returns, it seems that might answer to a similar question
is widely aproved, some maybe it's of interest :
http://programmers.stackexchange.com/questions/58237/are-break-and-continue-bad-programming-practices/58253#58253

(about early breaks/return/continue)
"When used at the start of a block, as first checks made, they act like
preconditions, so it's good.

When used in the middle of the block, with some code around, they act like hidden traps, so it's bad."

The other answers and commetns are interesting to read too.

Anyway I think it's offtopic and such discussion could be done on another more appropriate mailing list or website.

Klaim - Joël Lamotte.