lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

KHMan wrote:

To me it's just a library. No different from the rest. Why does it have to look different? We did fine before with lower case.

Leaving aside the aliasing, many people are attuned to having all caps as constants.


...[snip] and one becomes attuned to quickly scanning source code patterns in that way. [snip]...

I agree on that. For me code readability is paramount (I rarely need extreme performance, so my focus is biased).

Especially when scanning visually large sections of code, an all caps identifier shouts to my brain "I'm a CONSTANT!". If a function had such a name I will lose some milliseconds ( :-) )in telling my brain "hold on! It's just bit32 stuff". It's not really a pain, but it's a huge "distractor", ie. background noise. No showstopper at all, sure, and human minds are flexible enough to adapt, with time, but ... why this useless exercise? _ENV had to be ugly on purpose (I totally agree), but bit operations? If ugliness has a purpose, it should be that of telling the coder "BEWARE! You are walking on thin ice! Know what you are doing!"

After all, if the answer is "you can rename that", well, we can also have bit32.bit_and or lua_bit_library_32.BIT_AND or whatever (and for the same reasons also string.match_iter or matchiter instead of gmatch - what is "global" here?!?).

As KHMan hinted, there is some "mental" overhead in renaming things (and some organizational too - different projects - different coders - so you must establish a convention to rename things all the same), so it should be a practice IMHO limited to places where you have got no (easy) alternative.

Since bit32 is a new library, there is no legacy burden (beside possible clashes with Mike Pall's bitlib), why adding noise and inconvenience?

Many people on this list have suggested some alternatives (me too - I must admit). I don't see any advantage of having all caps AND instead of _and or b_and (ruling out "band" to avoid clashes with bitlib, If I got it right). They all sucks, in a way, but since also lhf said that AND sucks, well ... IMHO I think:
_and, b_and
or even:
and32, and_, __and__ (only 1 leading + 1 trailing underscore intended - my client insists on underlining)
suck a bit less (no pun intended), and they are less "noisy".