5 ms·

> Use a bigger font size. >... >The effect is: you're forced to write shorter methods. And that's a Good Thing. I find the opposite is true - I need to see m

by zmimon 18y ago

> Use a bigger font size. >... >The effect is: you're forced to write shorter methods. And that's a Good Thing. I find the opposite is true - I need to see more lines to appreciate exactly how goddamn awful that 200 line function is. And when I go to refactor it I need to be able to see as much as possible of it on the screen to start extracting bits out and make it shorter without losing context.

gnaritas 18y ago
He was talking about writing short methods to begin with, not fixing the already borked ones.
- jrockway 18y ago
  Yeah, great advice. Programmers should also stop writing bugs, too. How hard is it to GET IT RIGHT THE FIRST TIME?! All this bug hunting (and fixing) is a time waster. (Sarcasm alert.)
  - gnaritas 18y ago
    You're kidding right? It's pretty simple to write small methods from the start, trivial in fact. If you think small methods come from lot's of cutting up of larger methods then you're doing it wrong. Writing well factored code isn't some magic trick that requires doing it wrong first and then refactoring to get it right. Your sarcasm is misplaced and presumes bad code always comes before good code, it doesn't.
    - jrockway 18y ago
      I'm saying that it's easy to always try to do something, it's not always easy to succeed the first time. You should always make it easy for yourself to fix mistakes, even if you shouldn't have made them in the first place.
  - jlouis 18y ago
    Heh, but fact is that not adding the bug in the first place is better than spending time fixing it later. So you must catch problems quickly and attack them swiftly. There is a nice self-regulation principle at work here: If you make software with a lot of bugs, you also spend time fixing those bugs. This hampers your ability to make more crap software. If you on the other hand produce quality software, much less time is spent at maintenance so you become more productive overall. I think it is a fallacy to expect bugs to creep into your code. Eradicate them before writing the code lines. But what makes this hard for most people is that you don't think you need that amount of quality in your software.

by zmimon 18y ago

gnaritas 18y ago

He was talking about writing short methods to begin with, not fixing the already borked ones.

jrockway 18y ago
Yeah, great advice. Programmers should also stop writing bugs, too. How hard is it to GET IT RIGHT THE FIRST TIME?! All this bug hunting (and fixing) is a time waster. (Sarcasm alert.)
- gnaritas 18y ago
  You're kidding right? It's pretty simple to write small methods from the start, trivial in fact. If you think small methods come from lot's of cutting up of larger methods then you're doing it wrong. Writing well factored code isn't some magic trick that requires doing it wrong first and then refactoring to get it right. Your sarcasm is misplaced and presumes bad code always comes before good code, it doesn't.
  - jrockway 18y ago
    I'm saying that it's easy to always try to do something, it's not always easy to succeed the first time. You should always make it easy for yourself to fix mistakes, even if you shouldn't have made them in the first place.
- jlouis 18y ago
  Heh, but fact is that not adding the bug in the first place is better than spending time fixing it later. So you must catch problems quickly and attack them swiftly. There is a nice self-regulation principle at work here: If you make software with a lot of bugs, you also spend time fixing those bugs. This hampers your ability to make more crap software. If you on the other hand produce quality software, much less time is spent at maintenance so you become more productive overall. I think it is a fallacy to expect bugs to creep into your code. Eradicate them before writing the code lines. But what makes this hard for most people is that you don't think you need that amount of quality in your software.