konsu
1/21/2006 5:20:00 AM
Hello,
i believe that synonyms make code less maintainable.
konstantin
"cadience" <cadience@gmail.com> wrote in message
news:1137817020.027228.178100@g49g2000cwa.googlegroups.com...
> I've seen some discussion on synonyms in various message threads and
> would like to start a topic purely for this subject.
>
> ...Mounting the soapbox of my opinion...
>
> I see two camps for arguments about synonyms, being
> Reading/maintaining (booooh synonyms)
> Writing ( well, they are neat ....kindof)
>
> It appears that these are two warring factions, but I do not believe
> they are mutually exclusive.
>
>>From a writing standpoint:
>
> Synonyms give you the power to quickly use a class for the first time
> by "guessing" what the right function might be. For instance,
> Array.size and Array.length. Sure, they both do the same thing. Of
> course, dependent on a coder's background , one or the other will be
> more natural and have a tendency to fly from fingers to keyboard before
> a conscious thought. This will be a hard habit to break. If it is a
> natural idiom, then make it a synonum.
>
> The point is, the first time I tried to write code using an array (and
> that was 2 hours ago) it worked because I used Array.length. If Ruby
> forced me to use size, I would have had to look it up (groan!). For the
> next two weeks, I would have then proceeded to type Array.length -every
> time- only to realize I have to correct myself and type Array.size.
> Sometimes I would catch this, sometimes the computer would yell at me.
>
> The concept of supporting multiple ways of harnessing the coder's
> consciousness is germane to Ruby being an "interactive" style language.
> IF two camps of programmers from different backgrounds can both use
> Ruby to achieve the same results, great. The more people that can
> quickly pick up a language and just DO something the more appeal the
> language will have. You are coding to DO something, right?
>
>>From the reading standpoint:
>
> Conversely, If I happened to see both Array.size and Array.length in
> code I would have a high level of confidence about the general
> behavior, even if I never saw Array.size before.
>
> If you are reading someone else's code to learn Ruby, and you don't
> know the function, look it up! That is, after all, why you are reading
> the code in the first place. If it's obvious; yet another good reason
> for the synonym
> .
> If you are maintaining someone else's code - if it's not broke,
> don't fix it. More often than not the coder made a decision to do so -
> even it was purely his/her style. If it is an issue, give the person
> feedback -then they will learn. If you got stuck with the code
> because someone left your company, you should, of course, be learning
> the code. But if a synonym choice bothers you - change it... it is
> your code. If this really is an issue for a open source/company project
> then thy 10 commandments of coding style should say "thy will always
> use Array.length".
>
> When testing a code fragment, it is the operation of the code you are
> concerned with; the results produced by the code versus what's
> expected. The synonym choice will not change the test's outcome. You
> are looking for results. This includes debugging; after all debugging
> is simply the act of fixing code that failed a test. Sadly, most of the
> time this test was not explicitly created.
>
> This brings me full circle. Synonyms allow the coder to put down code
> quickly, in a form that is more likely to pass an implicit test - such
> as accessing a function of an object using the correct name.
>
>
> I hope what I said generates a lot of discussion focused on this topic.
> It may not be agreeable to you, but all the more reason for you to post
> you opinion!
>