3 ms·

Every line of code is a constraint working against you.

by dchichkov 14y ago

baddox 14y ago
.split("/n").join(";")
- hayksaakian 14y ago
  sorry for being pedantic, but should'nt it be "\n" ?
  - baddox 14y ago
    I just used the first slash I could find on the iPhone keyboard. You're right.
  - 1337Coder 14y ago
    sorry for being pedantic, but should'nt it be shouldn't?
- dchichkov 14y ago
  There is a little bit of ASCII art in any well written code. And yours would ruin it ;)
  - gruseom 14y ago
    That's a subtle comment and a much deeper one than it might appear to be.
    - deleted 14y ago
      [deleted]
- Someone 14y ago
  There 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?
  - baddox 14y ago
    I don't really know. I had Ruby in mind, and it seems to mostly work there, but still obviously breaks for things like heredoc multiline strings. Of course, the point is that making generalizations about the line count of a program is silly, because the line count can vary wildly between two semantically identical programs.
k3n 14y ago
I'm in agreement in that I believe, with all else being equal, every LoC increases your chances of initial bugs (and/or security vulnerabilities) and refactoring errors. It will also make the code take longer to mentally parse and interpret, not to mention that it means you will see less code on the screen at one time. None of these points are universal truths or anything, rather, given 2 solutions that identical in everything except line-count, choose the shorter. * BIG NOTE * This excludes code which is artificially short due to 'clever' coding.

Every line of code is a constraint working against you.

baddox 14y ago

.split("/n").join(";")

hayksaakian 14y ago
sorry for being pedantic, but should'nt it be "\n" ?
- baddox 14y ago
  I just used the first slash I could find on the iPhone keyboard. You're right.
- 1337Coder 14y ago
  sorry for being pedantic, but should'nt it be shouldn't?
dchichkov 14y ago
There is a little bit of ASCII art in any well written code. And yours would ruin it ;)
- gruseom 14y ago
  That's a subtle comment and a much deeper one than it might appear to be.
  - deleted 14y ago
    [deleted]
Someone 14y ago
There 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?
- baddox 14y ago
  I don't really know. I had Ruby in mind, and it seems to mostly work there, but still obviously breaks for things like heredoc multiline strings. Of course, the point is that making generalizations about the line count of a program is silly, because the line count can vary wildly between two semantically identical programs.

k3n 14y ago

I'm in agreement in that I believe, with all else being equal, every LoC increases your chances of initial bugs (and/or security vulnerabilities) and refactoring errors. It will also make the code take longer to mentally parse and interpret, not to mention that it means you will see less code on the screen at one time. None of these points are universal truths or anything, rather, given 2 solutions that identical in everything except line-count, choose the shorter. * BIG NOTE * This excludes code which is artificially short due to 'clever' coding.