The source of sickness is a patient. To be a most succesfull practical doctor one must reduce the number of patients he has. Best doctor is the one who doesn’t have any.
No patients - no illnesses.
No code - no debugging, no problems, no slipless nights, no nightmares.
All this article sounds like horse-rider talk about cars and all machinery. You don’t like cars - ride your horse and don’t complain. You don’t like programming and coding - do cleaning, cooking, babysitting, you name it. Just don’t tell me that any problem can be solved in three lines of code. I simply don’t believe it and I can give you examples if you’d like to see ones. Programming naturally IS solving problems work. If you are not happy to deal with problems - programming is not your area.
There is too much emphasis on patterns and too little emphasis on writing efficient, compact code.
Despite all the methodologies and “project science” software is still bloated, uses too much memory (memory is cheap, so what the heck), slow and/or buggy (in need of hotfixes) or pulls you into the configuration hell (declarative programming, anyone?).
It seems that all advances in hardware design are overtaken by software bloat.
Let’s have a looong discussion about pros/cons of singleton pattern or parameterless constructors. Let’s bloat. Blog. Reboot. Repeat.
What if you write two lines of code in your blog which don’t really accomplish anything and then about twelve hundred different people write their own version of those two lines. Would that be considered code-effective?
These kinds of articles encourage people to write three-line loops for ‘simplicity’ when fifteen lines performing several checks before the operation would be a cheaper solution.
Better way is to use static method String.IsNullOrEmpty(string).
Brevity should be in term of how you will shorten your code in function or class, not just one silly variable.
Nobody cares which one you use, because IT DOESN’T MATTER.
You really own to yourself to read your article and use proper example. You contradict yourself with the example as it is. It ain’t like the 2 lines you got there are hard to understand or one is harder than the other, it’s really just saving space like you say you are against before the example. Right after it, you say the first line is better cause it is shorter! What are you saying here, that you want shorter code or clearer code? I understand that you wish the later but you contradict that when you say :
“It seems obvious to me that the latter case is better because it’s just plain smaller. And yet I’m virtually guaranteed to encounter developers who will fight me, almost literally to the death, because they’re absolutely convinced that the verbosity of String.Empty is somehow friendlier to the compiler. As if I care about that. As if anyone cared about that!”
Your ideas in your blogs are good but you seem to shoot yourself in the foot with bad examples.
string.Empty is more explicit and likely more readable. Therefore it should trump “”.
Having said that, if choosing one of those two options is important, then the person choosing is either the best programmer in the world or probably wasting more time than any other programmer in the world…
I would use if (string.Empty == s) to prevent the common problem of doing an assignment when you intended to do a comparison. The compiler will catch the error for you as you cannot assign to a constant.
There’s also an interesting discussion around using either the .net types or the c# types. Do we use Int32 x = 0; or int x = 0; ?
I also agree that the intent is clarity, and not brevity, although clear code can be brief, but sometimes it’s a bit long winded. Whatever expresses the intent clearly is why I try to write.
I just want to say thank you to all the Pythonistas who reminded me that you can simply use 'if s:. I’d forgotten about that.
I regards to the main thrust of the article (as opposed to silly examples), I agree. In fact, it’s one of the major reasons I use Python pretty much to the exclusion of all else. It’s syntax is terse, but readble. It’s dynamic nature and other goodies reduce boilerplate.
I have read many of the comments but one of the issues I have found in maintaining other peoples code as well as updating older code I did not see listed. My favorite debuugging tool is stepping through the code. My greatest obsatcle to this is over-modularization. Any statement of database theory will caution the Database designer against over normalization. If there is no need to break up an Address field into separate fields for house number, Street directional prefix, ,street name, street type, and so on ad finitum then you should not do so.
However, over and over again, in debugging some one else code I will find a method, that calls two other methods that each call two other methods and so on and so on until you reach the point at which the actual task is actually performed in a little one or two line method.
Now I am not advocating a return to spaghetti code or the dispensation of object-oriented methodology. I am merely advocating moderation in everything. If you have to track 15 method calls in 5 different classes to find out one one method is doing, I’d say your code is too convoluted. The first principal in coding as in any field of engineering is KISS.
Code is the implementation of an algorithm. Large code is the result of a bad algorithm. The flexibility offered by modern day programming languages,scripts,etc mean that developers have countless ways to solve the same problem, but at the end of the day, one implementation will be the fastest which is the point of computer science and all that useless jargon that describes abstractions. Depending on your environment, if ur the lone wolf or part of a group, verbosity will become a requirement of the algorithm. Therefore it cannot be considered overhead if is necessary for it to be quickly understood and propagated by numerous individuals. The only other limitation would then be the analysis of the algorithms, a topic bashed to death. I don’t see the point of this article, if not to show that, like code, lots of letters can feel up space but are unnecessary. did i just diss mysself?!
Taken as a general philosophy, being concise is much better than the alternative. However, my perspective is that regardless of how verbose or structured, the most important aspect of any project is the documentation. Specifically to code development, this means annotation. Identify the problem, articulate the algorythm, distill the essential components, write the code. Annotate the hell out of everything.
Sp[Sf.E0Z]=function Sp$$E0z(){
var t=this;
if (t[Sf.E0O](c)) {return;}
var s=Z+this.toString();
var a,m=multiline;
var f=Sf.FCC;
var X=f(92),Y=f(47),CR=f(13),NL=f(10),Q=f(34),B=f(32);
var g=g,k=.,[]{}()+=-;+Q+*/^$:!|abcedfghijklmnopqrstuvwxyz_1234567890;
Rf[m]=T;s=s.R(n_R(Y+X+*[^+X+x01]*+X+*+Y,g),Z);Rf[m]=F;
a=[s];
if(s.IO(NL)!=-1) {a=s.P(NL);}else{if(s.IO(CR)!=-1){a=s.P(CR);}}
f=n_F(s,return +Q+Q++(s[L]/s.CCA(0))+s;);
s=a.J(NL);
s=s.R(n_R(X+Y+X+Y+[^+X+n]*,g),Z);
s=f(s);s=s.R(n_R(B,g),Z);
s=f(s);s=s.R(n_R(X+n,g),Z);
for (var x=0;xk[L];x++) {var c=k.CA(x);s=f(s);s=s.P(c).R().J(c);}
var r=Z;
var xi=Math.floor(s[L]/100)+1;
for(var x=0;xs[L];x+=xi) {r+=s.SS(x,1);}
return r+s;
};
I think Scala brings balance among the dimensions mentioned by Wil Shipley. That doesn’t mean one cannot write unreadable code in Scala; but as Stuart Halloway states, it captures essence over ceremony.
var result = from x in source select x*x;
vs.
result = [x**2 for x in source]
I gotta say the Python code is a more understandable to me than some quasi-SQL query.
Also, not sure if you know, but:
In the Python code snippet we know that the type of the result is a normal list. What is the type of the result of the C# query? Can you replace “var” with an actual type? If not, can you return the results of the query from a method?
I.e. can you do:
something? Func (Something source) {
return from x in source select x*x;
}
I agree with the concept, but think you picked a poor example. The goal is no code - think of a way to do your work without writing custom code.
However, if you need to write custom code, please don’t save keystrokes to be “elegant”. Once you’ve crossed over to writing some code, express your intent. For instance, “s” is a terrible variable name since it expresses absolutely no intent. I know it’s sample code, but the point is that your logic - “” is better than string.Empty because it’s fewer keystrokes - also dictates that “s” is better than “state” or “sorority” or “satanicRitual” or “stepSister”.
Unsubscribed! Okay, re-subscribed, but it’s probationary!
or parameterless constructors. Let’s bloat. Blog. Reboot. Repeat.
