Is this kind of practice accepted

  • Thread starter Thread starter Alvin Bruney [MVP]
  • Start date Start date
A

Alvin Bruney [MVP]

Consider this:

Data.Biz.User user = new
Data.Biz.User(Logic.Biz.User.connectionstring,Logic.Biz.User.Lib);
//returns a datatable
DataTable dt = user.UserInfoSearch(buffer.ToString());
DataSet ds = new DataSet();
ds.Tables.Add(dt);
return ds;

can be turned into this peice of poetry

System.Data.DataSet ds = new System.Data.DataSet();
ds.Tables.Add(new
Data.Biz.User(Logic.Biz.User.connectionstring,Logic.Biz.User.Lib).GetAgents());

return ds;

I find it very sexy that i can do everything in one line of code. Anybody
see readability problems with that? I'm thinking if you can't read this code
you shouldn't be working on the project anyway. Any recommended patterns and
practices against this approach?
 
Bunching up 5 lines of code into 1 definitely makes it less readable. And
it's not that one can't read it - it's that it becomes more difficult for
someone unfamiliar with the code to figure out what's going on.

Perhaps you can find a compromise someplace in the middle. So not have 5
nested calls all in one line - but not have too many lines of code either.
 
i see your point, but from my C++ days we were taught to read from the end
of the line inwards. a reasonably talented programmer should have not
problems with this construct since it is a basic tenet of programming.

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok
Marina said:
Bunching up 5 lines of code into 1 definitely makes it less readable. And
it's not that one can't read it - it's that it becomes more difficult for
someone unfamiliar with the code to figure out what's going on.

Perhaps you can find a compromise someplace in the middle. So not have 5
nested calls all in one line - but not have too many lines of code either.

Alvin Bruney said:
Consider this:

Data.Biz.User user = new
Data.Biz.User(Logic.Biz.User.connectionstring,Logic.Biz.User.Lib);
//returns a datatable
DataTable dt = user.UserInfoSearch(buffer.ToString());
DataSet ds = new DataSet();
ds.Tables.Add(dt);
return ds;

can be turned into this peice of poetry

System.Data.DataSet ds = new System.Data.DataSet();
ds.Tables.Add(new
Data.Biz.User(Logic.Biz.User.connectionstring,Logic.Biz.User.Lib).GetAgents(
));

return ds;

I find it very sexy that i can do everything in one line of code. Anybody
see readability problems with that? I'm thinking if you can't read this code
you shouldn't be working on the project anyway. Any recommended patterns and
practices against this approach?

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok
Click to expand...
Click to expand...
 
i see your point, but from my C++ days we were taught to read from the end
of the line inwards. a reasonably talented programmer should have not
problems with this construct since it is a basic tenet of programming.
Click to expand...

There's a difference between "be able to read after a while" and "the
most readable form of the code".

I would personally prefer the several line version.
 
I agree... Plus, much easier to set breakpoints on the multiple lines of
code.

--
HTH

Kyril Magnos
"I'm not a developer anymore, I'm a software engineer now!" :-)

| <"Alvin Bruney [MVP]" <vapor at steaming post office>> wrote:
| > i see your point, but from my C++ days we were taught to read from the
end
| > of the line inwards. a reasonably talented programmer should have not
| > problems with this construct since it is a basic tenet of programming.
|
| There's a difference between "be able to read after a while" and "the
| most readable form of the code".
|
| I would personally prefer the several line version.
|
| --
| Jon Skeet - <[email protected]>
| http://www.pobox.com/~skeet
| If replying to the group, please do not mail me too
 
well the break point is really not an issue since you can step into the
function or choose to break on an exception. i still am a bit awestruck that
this code is not immediately readable, or is it just that we are accustomed
to one line of code does one thing...
 
well the break point is really not an issue since you can step into the
function or choose to break on an exception.
Click to expand...

It makes it harder to break into one particular bit of code flow at
exactly the right point though.
i still am a bit awestruck that this code is not immediately
readable, or is it just that we are accustomed to one line of code
does one thing...
Click to expand...

The line is 98 characters long even before you take into account any
whitespace preceding it. While it's occasionally worth having long
lines if you can't easily split them up, in this case you've shown that
there's a perfectly simple way of splitting it up.

It's definitely not immediately readable - not as readable as the
multi-line version.
 
vapor at steaming post office (Alvin Bruney [MVP]) wrote in
I find it very sexy that i can do everything in one line of code.
Anybody see readability problems with that? I'm thinking if you
can't read this code you shouldn't be working on the project
anyway. Any recommended patterns and practices against this
approach?
Click to expand...

Put yourself in the shoes of the person who will come after you and
have to maintain that piece of "poetry".

Do you think he'll marvel at your cleverness and skill, or do you
suppose he might be thinking something else entirely?
 
he won't come, it's called job security. they'll contract me to come and
adjust the poetry.

point well taken though
 
Alvin Bruney said:
I find it very sexy that i can do everything in one line of code. Anybody
see readability problems with that? I'm thinking if you can't read this code
you shouldn't be working on the project anyway. Any recommended patterns and
practices against this approach?
Click to expand...

I've done a whole lot of this sort of thing in the past (and present) for
many of the same reasons. It's just plain cool how much power you can wrap
up into one line of code. Seeing those same lines of code, years later when
my mind is not buzzing from total immersion in the project, I often ask
myself "WTF was I thinking?". They make perfect sense when I am "in it",
and none when I am not. And rarely do they make sense to someone else on
the project with me, in much the same way as their one-line beauties don't
make sense to me. They are sort of like artistic creations open to
interpretation (in fact, requiring interpretation!). That's where the
breakdown occurs, and people give up, and toss out your code. And mine.

For a program/application/system to have a long and healthy life, it helps
immensely if the intent of a code fragment is as clear as possible, as soon
as you look at it. I might even consider this to be mandatory. Having to
think about a line of code is not something you want to do when you are
maintaining someone else's code. Frankly, it just pisses me off, and this
is even worse when it's my own damn code.

So, I have a question for you:

If breaking it up and/or spelling it out results in code which is easier for
others to understand, easier to debug, and runs the same as the single line
version, then why not do it?

Best Regards,

Andy
 
Jerry Pisk said:
Because if it was difficult to write it should be difficult to read ;)

Jerry
Click to expand...

This gave me an ear to ear grin when I read it, which was sorely needed
today (does it show?!). In the Compuserve days we used to call them BFGs.

Best Regards,

Andy
 
Back
Top