Lousy Attribute Name:
self.tmp
Accessors:
set_temporary_buffer
get_temporary_buffer
The attribute name I chose, "tmp" sucks. I have used that name in
dozens of places spanning over 27000 LOC. There's a chance that other
develops might misinterpret exactly what "tmp" does. Plus I don't want
emails from other developers querying me about what "tmp" is/does.
"tmp" is obvious to me, but not necessarily to others. Now compare that
to the accessors. Not only do they improve readability at the expense
of more code, they actually allow me to change the lousily named
attribute "tmp" to "temporary_buffer" without grepping, seding,
searching, replacing and praying. Sure, if you are dealing with less
than a 1000LOC you can get away with using "tmp" or renaming it easily.
But if you are dealing with a much larger code base and more
developers, issues like this rapidly become a nuisance.
Yes, it is possible to name crappy accessors too (e.g set_tmp/get_tmp).
But developers tend to pay more attention to given methods/functions
less crappy names, at least when compared to data attributes. This
stems from the fact that in many languages data attributes aren't
usually part of the API, as well as the whole OO(Encapsulation) blah
blah. I know I would not name the accessors set_tmp/get_tmp, because my
philosophy is that methods/functions need to have meaningful names and
state their intended purpose. I don't hold data attributes to such
standards and I imagine many developers don't either and least based on
other people's code I've read. Plus there are many occassions when
attributes are not intended to be APIs, but eventually become one.
After all most data attributes are created with the purpose of serving
methods.
Bruno Desthuilliers wrote:
> mystilleef wrote:
> > Hello,
> >
> > Thanks for the responses. The reason I want to change the name of the
> > attribute is because it doesn't reflect the purpose of the attribute,
> > anymore. The attribute was originally a string object, but not anymore.
> > It is primarily a readability issue. There are also a few key
> > attributes I don't want developers, including myself, fiddling with.
> > Properties /accessors are good because they allow you to encapsulate
> > attributes so you can change implementations at will. Some of you have
> > argued I would have needed to change accessor names too if I had
> > misnamed them earlier. It's hard to say. I find myself changing the
> > names of attributes a lot more frequently than I do functions or
> > methods. Choosing a crappy attribute name is effortless for me,
> > especially during intense coding sessions. I usually realize I've
> > choosing a crappy attribute name the next day, sometimes even later.
> > However, I put a lot more effort into choosing method and function
> > names, especially when I know it may likely be a public API.
>
> What you need to understand here is that in Python,
> 1/ methods *are* attributes
> 2/ every attribute whose name is not prefixed by a leading underscore is
> considered part of the api ('__magic__' names being a special case).
>
> So it has nothing to do with "data vs method" dichotomy (which makes no
> sens in a languages where functions and methods are objects), only with
> "API vs implementation". You choosed a crappy name for an attribute
> that's part of the API, so it's *exactly* the same case as if you had
> chosen a crappy name for a public method in Java. Think of public "data"
> attributes as magical getter/setters with the most straightforward
> behaviour, and of properties as the way to override this default behaviour.
>
> > Plus it's
> > really hard to choose crappy accessor name.
>
> What about getMyCrappyAttributeName/setMyCrappyAttributeName ?-)
>
>
>
> --
> bruno desthuilliers
> python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
> p in '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
