7 ms·
How important is it to reduce the number of lines in code?
- jfaucett 14y agopersonally, i think that when you're programming, not just pondering how to make your code simpler and shorter but also concentrating on patterns that repeat and packing them into a catchall solution can do a lot towards making code more readable and maintainable. I suppose this is what is usually meant by DRY, but I unfortunately still see an aweful lot of code that doesnt follow this principle. And i think it has to do with the fact that many (myself included) programmers think about solving the problem at hand and we sometimes allow our thoughts about abstracting what we're doing into overarching reusuable procedures to slip into the background. for instance, say you notice you've got multiple for loops iterating over matrixes of pixel data and running transformation functions on member elements. The first level would be to abstract this into an each function taking the array and the function to call, the next step would be to pack the each into an even more general function, and now all those lines have been compacted into a single call pixel_data.update_array_matrix.
- dvt 14y agoThings are complicated, but it's a well-known fact that lines-of-code is literally the worst metric of source-code health. Lines-of-code have been previously used as a productivity metric and as an efficiency metric, but in the past several decades, LOC has been debunked as virtually worthless in both cases. In other words, if you're thinking "that guy must be productive, he wrote twice as many lines as this other guy" or "this code must be slower since it's 3 times longer than that code" you're most likely wrong in both cases. Or, in the best case, very naive. And what's up with Ars Technica just copy-pasting SO (or prog.SE) answers into an article?
- RougeFemme 14y agoLOC is also used as a "maintainability" metric. Don't know how useful it is. I assume it would need to be massaged with some other metrics - or at least placed in proper context, whatever that means in your environment. Also, if your code verges on throw-away, maintainability would not be a consideration.
- dchichkov 14y agoEvery line of code is a constraint working against you.
- baddox 14y ago.split("/n").join(";")
- hayksaakian 14y agosorry for being pedantic, but should'nt it be "\n" ?
- dchichkov 14y agoThere is a little bit of ASCII art in any well written code. And yours would ruin it ;)
- gruseom 14y agoThat's a subtle comment and a much deeper one than it might appear to be.
- deleted 14y ago[deleted]
- Someone 14y agoThere are few, if any, languages where that would be guaranteed to work. For example: in C #include <studio.h>#include <stdlib.h> won't work. In perl, strings with literal new lines or here docs will break (terminator must be on a line by itself) Any language with 'comment till end of line' would break. Any language that does not use semicolons as statement terminator or separator such as Forth, Postscript, and XML-based languages wouldn't like the inserted semicolons. Even pascal would break, as it has a few places where repeated semicolons are illegal, as in the third line of type T = record a : integer; end; Algol has a problem changing if x=4 then y:=5 else y:=6; into if x=4 then y:=5;else y:=6; Because a semicolon is a statement separator in Algol (I think pascal has this problem, too) So, can anybody suggest a language where this would work?
- Manishearth 14y agoDepends. Does it make it cleaner, faster, and more readable? Go for it. Does it just use syntactic sugar to cram stuff into one line? Don't do it.
- Paul_D_Santana 14y agoThe #1 most important factor in coding is: Will I be able to read my code tomorrow or next week and know what in the heck I did?
- timr 14y agoWhich really means: did I spend the time to write good comments? People will go to endless lengths to make their code more terse and/or "self-documenting", but almost nobody takes the five extra minutes it takes to write an intelligent comment. The comments are far more important.
- randomdata 14y agoI have to wonder what a good comment gives that a good set of tests wouldn't also provide, plus all of the extra benefits that come from having automated tests? It seems like they both exist to solve the same problem (to explain intent, show usage, etc.), with just one being more formal about it.
- jfim 14y agoSometimes, code is hard to read due to being optimized. In that case, it's often easier to read a short comment than having to parse the code. // p.xyz += f.xyz * timeStep __m128 ts = _mm_load1_ps(&timeStep); __m128 x, y, z; __m128 fx, fy, fz; for(int i = 0; i < NUM_PARTICLES; i+=4) { x = _mm_load_ps(px + i); y = _mm_load_ps(py + i); z = _mm_load_ps(pz + i); fx = _mm_load_ps(pfx + i); fy = _mm_load_ps(pfy + i); fz = _mm_load_ps(pfz + i); x = _mm_add_ps(_mm_mul_ps(fx, ts), x); y = _mm_add_ps(_mm_mul_ps(fy, ts), y); z = _mm_add_ps(_mm_mul_ps(fz, ts), z); _mm_store_ps(px + i, x); _mm_store_ps(py + i, y); _mm_store_ps(pz + i, z); } Sometimes, it's because you're doing something that looks surprising, but is there for some reason, so that the next time someone looks at that code, they know why something is done in that fashion. val loginForm = Form( tuple( "email" -> text, "password" -> text, "rememberMe" -> optional(text) // jfim: HACK For some reason, having this as boolean causes a None.get in Play 2.1.0 ) ) Comments should be there to explain why the code does something or what it does in a more readable fashion(because it's faster to read plain English than code), neither of which can be covered by tests.
- niggler 14y agoWhat exactly did Ars Technica contribute to this discussion? It looks like a copy-paste job.
- deliminator 14y agoFollowing quote comes to mind (Dijkstra) "...we have to keep it crisp, disentangled, and simple if we refuse to be crushed by the complexities of our own making..." I found his use of the word "crisp" very interesting. I believe it means to keep your code short and to the point, without any extra embellishment.
- just2n 14y agoReducing the number of lines isn't important. Unless you're code golfing or otherwise competing to fit within a certain code/binary size, you should never care about line count at all. The only thing it will do is cause you to crush your lines wherever possible and code horizontally instead of vertically, which generally conflicts with readability. In fact, I'd actually impose a limit on line length to prevent just that. Instead, write code that makes sense when you read it. Avoid cleverness, and DRY. Repeating yourself in the way that violates DRY principles can often make reading code more difficult because you're essentially forced to re-read repetitive code because you can't assume it's all identical. The only exception to this is code standards for consistency in the code base that make sense, such as use a '{' on the same line as the definition or omit the '{}' block if the body is just 1 statement in cases where you won't violate a width constraint, etc. Anything that isn't completely reasonable as a code standard is optimizing for line count and is probably the wrong thing to do.
- jack9 14y ago> Reducing the number of lines isn't important. This is statistically false. It is the ONLY thing, we know, in CS, that is relevant to accuracy. The confounding effect of class size on the validity of object-oriented metrics - Subscribe by email Your email: Contributors Christoph Treude Felienne Hermans Greg Wilson Jorge Aranda Leif Singer Neil Ernst Recent Tweets profile Never Work in Theory neverworktheory neverworktheory Comments on Firefox Available for Analysis: wp.me/p1FcBp-8c 13 days ago · reply · retweet · favorite neverworktheory Halving Fail Rates using Peer Instruction: wp.me/p1FcBp-87 29 days ago · reply · retweet · favorite neverworktheory Experimental Assessment of Software Metrics Using Automated Refactoring: wp.me/p1FcBp-7S 53 days ago · reply · retweet · favorite neverworktheory MSR 2013 – Call for Papers: wp.me/p1FcBp-7E 67 days ago · reply · retweet · favorite Join the conversation Categories Announcements Book Reviews Case Studies Code Ownership Code Review Code Smells Collaboration Controlled Experiments Documentation Education Estimation Experience Reports General Literature Reviews Meta Metrics Mining Noticed Open Source Organizational Studies Pair Programming Practices Programming Languages Qualitative Studies Quality Quantitative Studies Questions Refactoring Reproducibility Scientific Computing Survey Testing Tools Uncategorized Usability Verification Video Recent comments Geert Bollen on Why We Need Evidence Graham on Experimental Assessment of Software Metrics Using Automated Refactoring Willem van den Ende on Experimental Assessment of Software Metrics Using Automated Refactoring FelienneHermans on Experimental Assessment of Software Metrics Using Automated Refactoring Willem van den Ende on Experimental Assessment of Software Metrics Using Automated Refactoring The Confounding Effect of Class Size on the Validity of Object-Oriented Metrics July 7, 2011 gvwilson 3 comments Khaled El Emam, Saida Benlarbi, Nishith Goel, and Shesh N. Rai: “The Confounding Effect of Class Size on the Validity of Object-Oriented Metrics“. IEEE Transasctions on Software Engineering, 27(7), July 2001. Jesus, how do you comment (weakly) on a well-understood topic, without any understanding of the domain? I dunno, ask just2n.
- codygman 14y agoThe only metric you should work on reducing in your program is complexity. Of course, some complexity/warts will be needed.
- mark_l_watson 14y agoI have actually been programming since I was a kid (I got access to computers around 1962). I used to write huge blocks of comments, and even simpler programs had a high LOC count. I work differently now. I mostly work in Clojure and I write very few comments but I like long and descriptive function and variable names. I think that a concise language like Clojure or Ruby, combined with very good semantic naming works much better for me. I can look at year old code, and fall right into it.
- k3n 14y agoIt has everything to do with context, and the ultimate goal should be clarity for the reader. But, I also don't think you should ever compromise any non-trivial design for the worse to 'make it more readable'. Sometimes clever code can't be easily avoided, whether it's due to language limitations or the general design pattern itself, so proceed with caution and use lots of comments in those cases. A quick example here would be a factory method: since you're often referring to abstracted resources, you can't really make a non-clever factory without entirely defeating the purpose of the factory. Another example would be from PHP, where you can many times do tasks in several different ways, and so you may have this code (straight from the manual) for reading the contents of a file: $filename = "/usr/local/something.txt"; $handle = fopen($filename, "r"); $contents = fread($handle, filesize($filename)); fclose($handle); And this isn't even very descriptive, unless you have a background in other languages such as C to grok that filesize($filename) might mean "read to the end of the file". OTOH, this code does the exact same thing and is extremely explicit about what it's doing: $contents = file_get_contents("/usr/local/something.txt");