Wait a second, I always thought it was called PascalCase, and camelCase is like that
On Thu, Sep 4, 2008 at 1:36 PM, Casey Duncan <[EMAIL PROTECTED]> wrote: > On Sep 4, 2008, at 12:12 PM, Ian Mallett wrote: > >> On Thu, Sep 4, 2008 at 8:15 AM, kschnee <[EMAIL PROTECTED]> wrote: On a >> dissenting note, I'm one of those deviants who names functions with >> CamelCase, on the theory that lc_with_underscores confuses functions and >> variables. >> Me as well--only I use uppercase for pretty much everything--from >> functions to classes and variables (although in the case of class methods, I >> often use lowercase). It is all a question of aesthetics, to me. I assumed >> a standard, but I don't really care about standards :P I also didn't know >> it was called "CamelCase". >> >> For example, if SpaceRock is a class, an instance might be like Asteroid1 >> = SpaceRock(). A method might be Asteroid1.explode() because Explode() >> doesn't look right to me. I might make a variable Screen = (800,600) >> because that looks nice. >> >> I know, crimes against Python-ity. So sue me. Anyway, irrelevant topic; >> back to reality! > > Consistency within your own code is probably most important. But if you are > writing a library that you expect other people to use, following the pep 8 > guidelines is a very good idea. Conventions like these, however arbitrary, > make it much easier for others to understand and use your code. And this can > be leveraged for purely selfish reasons as well, it's a lot easier for > people to help you fix problems with your code if it's easy for them to > understand. > > -Casey > >
