Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re(3): Of variable {mice} and its name {man}.

by Dog and Pony (Priest)
on Jun 03, 2002 at 07:28 UTC ( [id://171156]=note: print w/replies, xml ) Need Help??


in reply to Re: Re: Of variable {mice} and its name {man}.
in thread Of variable {mice} and its name {man}.

I almost have to assume that you misinterpret this on purpose, possibly to point out that I wasn't very exact in my post. In any case:

You are confusing "how comments" and "what comments". In the example taken from Refactoring, you don't seriously believe that the name of the new sub should describe how the code works? No, it describe what it does, and what it is for. That should be pretty obvious.

Then for most code, especially in small blocks with good names, it should be quite clear what is happening from just reading the code - some people even advocate that if the code is well-written, it should not need any comments whatsoever. That I can't really agree on, there are always hairy parts that needs extra explaining. And as someone once said: "Good code has lots of comments, bad code needs lots of comments." - meaning that you should always comment your code, no matter which of them you write... especially since who are you to tell? :)

You think that it is somehow mutually exclusive with comments and verbose names. Why? Where did I say that you can't explain your data structure because you have a good name? The name is there so you can see what data is being worked on in the code, not so you can see how. That either is easy enough to read from the surrounding code, or is documented somewhere where it is easy to find.

Again, how contra what.

Documenting the variables name once like thus:

# Holds all employees names my @em;
instead of naming it something like:
my @employee_name;
is your choice then? Well, it is not mine. If I have a semisized piece of code, then I don't want to have to go to the top of the program (potentially) to find out what each variable holds, each time I encounter them. If I know what data is in it, from the name, then I can work on. If I don't know the data structure, and it isn't possible to (easily) deduce from the surrounding code, then I'll go look for some docs on the structure. What or how.

Perl programmers often pride themselves on "Laziness", since it is one of the programmer's virtues according to Larry Wall. Well, there is false laziness too. Trying to "save time" by typing a few less keys is definetely false laziness - at least if you are trying to hold that as a virtue. As the XP and refactoring people say about writing tests - you have the extra time for it, because you didn't really code all, or even most of the time that you sat at your computer anyways. As with tests, you can save a lot of maintenance and bug fixing by being clear about what happens. Even if apt naming isn't gonna do a big difference on its own, together the small things count. Beware of false laziness.


You have moved into a dark place.
It is pitch black. You are likely to be eaten by a grue.

Replies are listed 'Best First'.
Re: Re(3): Of variable {mice} and its name {man}.
by theorbtwo (Prior) on Jun 03, 2002 at 07:56 UTC

    Refactor your names, too. Is it significant to the code that these are employees? If not, @names is a perfect name. @en is overshorting. @employee_names is overspecifing.

    If it is significant to the code that these are empoyees you're naming, why? Does this mean that if you were dealing with customer names, the code would be completly inapproprate? Why?

    Every character really does count. (Check how many different ways I've mistyped employee in this post, and how many you noticed being wrong.)


    We are using here a powerful strategy of synthesis: wishful thinking. -- The Wizard Book

      Check how many different ways I've mistyped employee in this post, and how many you noticed being wrong.
      Nothing that strict and warnings wouldn't handle.
      You have moved into a dark place.
      It is pitch black. You are likely to be eaten by a grue.

        Right, but @names wouldn't have been mistyped in the first place. It's better to avoid errors then to fix them. (Given equvlent functionality.)


        We are using here a powerful strategy of synthesis: wishful thinking. -- The Wizard Book

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://171156]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (4)
As of 2024-03-29 01:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found