in reply to Re^2: What is code readability?
in thread What is code readability?
1st & 4th, my favourite one BTW, are much easier on the eyes.
There is one more variation ...
some_function ( some_variable , some_other_variable , and_yet_another_variable , and_one_more_for , luck )
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^4: What is code readability?
by BrowserUk (Patriarch) on Jan 04, 2007 at 05:45 UTC | |
Ug :) I really hate that. I see no benefit in spaces both sides of the commas, or breaking the open paren away from the function name. And if you have to break the params across lines, at least balance their lengths :)
That's not so bad for simple (void) calls as, but when you're retrieving data and checking you get something like
It's just a mess.The best I've come up with for this is
Which ain't great, but is better than most alternatives to my eyes. And much better still is
With the point being that whilst ths abbreviated variable names don't immediately make much sense, by the time a programmer has got familiar enough with the code to consider making changes, they will. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [Watch: Dir/Any] [d/l] [select] |
by wfsp (Abbot) on Jan 14, 2007 at 09:43 UTC | |
And you're always going to get all those args in the right order? I know I wouldn't.
I should point out I'm presently having terrible trouble debugging an app (that I'm writing). It gets more vertical by the day! :-)
| [reply] [Watch: Dir/Any] [d/l] |
by BrowserUk (Patriarch) on Jan 14, 2007 at 12:45 UTC | |
Hmm. I really do have a strong aversion to this vertical coding style. I've attempted to explain the reasons for this on many occasions here and elsewhere, but I'm not sure I've ever done so successfully. I may try again at the end of this post, or in another post. I'm also skeptical about the need for/benefits of named arguments. For example, there are very few functions in perlfunc that take more than 4 arguments. And for those that do, those beyond 4 are final LISTs that extend indefinitely in an obvious and unnameable way. Of those that (can) take four, non-list arguments, the ones I use regularly: splice, substr, index, rindex, vec, open/sysopen, read/sysread/syswrite; I do remember the ordering without any specific effort to do so. Of the others in perlfunc that take four or more args, most of which I have rarely if ever had occasion to use--mostly because they don't work or make little sense on my platform--I would have to look them up. But then, I'd have to look them up anyway just to know what they do, and what they require to do it--let alone what order they expect those things in. Of the APIs that use named argument interfaces that I use regularly, the IO::Socket::* constructor is probably the one I've used most. And if I ever need to call that in anything other than the simplest $sock = IO::Socket::INET->new('127.0.0.1:25'); form, I always have to look it up. In large part because I can never remember the correct capitalisation of the argument names! The upshot is that I think that There are occasions when it is necessary to have an API with more than 4 or 5 arguments and for which named arguments makes sense, but on those occasions there are several things that (IMO) should be true. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [Watch: Dir/Any] [d/l] [select] |
by Anonymous Monk on Sep 10, 2009 at 09:26 UTC | |
My take on it is pretty close, I just see OK to open more than one paren in a line (and hence close them all in the same line):
| [reply] [Watch: Dir/Any] [d/l] [select] |
by BrowserUk (Patriarch) on Sep 10, 2009 at 10:52 UTC | |
Yes, That's okay too, though I do prefer to have the indent level reflect the number of currently open parens. So:
but sensible length variable names (and camelCase :) are better.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [Watch: Dir/Any] [d/l] [select] |
Re^4: What is code readability?
by jdporter (Paladin) on Jan 04, 2007 at 05:37 UTC | |
There is one more variation Only one?
A word spoken in Mind will reach its own level, in the objective world, by its own weight
| [reply] [Watch: Dir/Any] [d/l] |
by parv (Parson) on Jan 04, 2007 at 06:16 UTC | |
Of course; I did not claim the posted version as "'only|sole|last' one variation" (but "a variation"). Problem with your first variation -- for that matter, any other code in which things are aligned along the columns -- is that aligning commas for short varaibles like "luck" is too much effort. (Second one is just ridiculous overkill.) (I was hoping not to contribute anything (as I do not have much to say about brain d foy's points) but I was suckered in anyway.) | [reply] [Watch: Dir/Any] |
| |
Re^4: What is code readability?
by Anonymous Monk on Jan 04, 2007 at 17:29 UTC | |
...getting better...
| [reply] [Watch: Dir/Any] [d/l] [select] |
by runrig (Abbot) on Nov 13, 2012 at 23:30 UTC | |
| [reply] [Watch: Dir/Any] |