
10 things you could be doing to your code right now - luccastera
http://smartic.us/2008/9/9/10-things-you-could-be-doing-to-your-code-right-now
======
zenspider
Just to add to the blog post a bit:

those flog scores interpretation are ONLY valid if you use them on a per-
method basis... on a per-file or per-project level they're completely invalid.

For example:

    
    
        % pwd; flog -n -m lib | head
        /Users/ryan/Work/p4/zss/src/ruby_parser/dev/
    
        Total Flog = 5284.4 (12.2 +/- 2852.7 flog / method)
        
        RubyLexer#yylex: (1076.9)
        RubyLexer#tokadd_string: (146.8)
        RubyLexer#read_escape: (130.5)
        RubyLexer#heredoc: (118.3)
        RubyLexer#heredoc_identifier: (89.6)
        RubyParser#literal_concat: (81.2)
        RubyParser#assignable: (65.2)
        RubyLexer#parse_quote: (63.4)
    

There is little I can do at this time to clean up the monstrous yylex, but
tokadd_string, read_escape, and heredoc are all too big and need some
attention to clean them up. Everything else is, relative to those scores,
reasonable and can be ignored at this time.

I am still chuckling that he recommends capistrano right after pushing tools
to fight complexity...

~~~
ivey
For the 80% case, cap works fine. It's when you need to do stuff in that last
20% that you have real trouble.

~~~
zenspider
I was in the 80% case when I wrote vlad. cap does NOT work fine. It is a
steaming pile of intertwined crap... imhfo.

We got the 80% usage case of vlad covered in about a 3rd( _) of the code that
cap required.

_ ) actually &pi;. In the release notes for vlad 1.1: "The flog ratio between
capistrano+deps / vlad+deps is pi (or, damn close)!". Line numbers correlated
fairly close iirc.

------
tptacek
A list with 7 different ways to do unit testing that doesn't include "N.
Adding features to it" is probably not a good list for a startup.

~~~
pius
Heh, unless you believe these guys:

<http://gettingreal.37signals.com/ch02_Build_Less.php>

:P

------
edw519
Every once in a while, a seemingly useful piece is posted here at hn that I
read and, based on what has worked well for me, I simply don't agree with.
This is one of those. Here goes:

 _1\. Upgrade Test::Unit - What, you aren’t testing? You should be testing all
the fucking time (TATFT)._

Except when you're coding. And then you shouldn't be doing anything but
coding. Sometimes you just gotta crank in order to make any real progress.
It's a lot easier to test once you have something to test.

 _2\. Try out some TDD - Test Drive Development (TDD) makes for better code._

No. Define your target. Code to it. Deploy. Then test. Lots of quick cycles
blow away few slower ones. Just code with your pedal to the floor. Test time
is the time for testing.

 _3\. Upgrade your fixtures - I’m not sure I can advocate this approach due to
the fact fixtures actually do provide some use._

Just because something provides _some_ use doesn't mean you should use it. Get
a good IDE or text editor, a good work area, and a little gray matter; that's
all you need. Otherwise, you risk getting caught up in all your cool tools, an
easy mistake to make.

 _4\. Install (and learn and use) a SCM - The benefits of having code in some
form of repository hugely outweighs it not being there._

Uh, I'd love to argue with this one, but I won't. Good advice. Either get some
kind of repository or learn to walk on eggshells. Your choice.

 _5\. Investigate Continuous Integration - ...makes automating your tests to
run at checkin next to trivial._

Making checkin trivial is not a goal while coding. Getting something done IS.
Anything that is not coding is not helping you make progress while coding.

 _6\. Know your code - It is one thing to write your code, but it is another
greater thing to know your code. Four automated tools..._

"Know your code" & "automated tools" are mutually exclusive. See my response
to #7 below.

 _7\. Automate your deployments - Automation is your best friend._

Wrong. This is EXACTLY to opposite of #6, "Know Your Code". Automation takes
you out of the very trenches you have to be in to get to know your code in the
first place. The dirtier I get, the better I know my code. (For further
reading, Chapter 3 of Founders at Work by Jessica Livingston. Woz (my hero)
totally immersed himself in his details without crutches in order to know them
as well as anyone ever has.)

 _8\. Collect some statistics_

Code now, get something working, and worry about analyzing it later. Again,
anything that isn't "coding" is slowing you down.

 _9\. Read other people’s code - You want to be a better developer? Read code.
Read bad code. Read good code. Read your code. Read my code. Code reading is a
skill that many developers skimp on._

I have NEVER liked this advice. Why? I've never found it the least bit
helpful. Either I didn't understand the code or it sucked so much, I was too
ill to work the rest of the day. Better: find something cool (on the outside)
and figure out how to code it yourself. Ask for help or suggestions if you
need it.

 _10\. Blog about it_

If you have time to blog, then your project isn't big enough. Code now,
deploy, and blog later. Frankly, I don't want to read about your "adventures
in development" until you're done and have something to say about your
(completed) work.

~~~
jrockway
_9\. Read other people’s code - You want to be a better developer? Read code.
Read bad code. Read good code. Read your code. Read my code. Code reading is a
skill that many developers skimp on.

I have NEVER liked this advice. Why? I've never found it the least bit
helpful. Either I didn't understand the code or it sucked so much, I was too
ill to work the rest of the day. Better: find something cool (on the outside)
and figure out how to code it yourself. Ask for help or suggestions if you
need it._

Your advice is bad. Programming is like writing -- you get ideas from reading.
Did you learn to write by "figuring things out", or did you learn to write
from imitating what you've read?

Personally, I think the #1 problem with programmers is that they are afraid to
read other people's code. They treat libraries like they are magic. They
aren't, they're just like the code that your app is written in. Finally, if
everyone else's code looks really different from yours, you are probably doing
it wrong.

 _If you have time to blog, then your project isn't big enough. Code now,
deploy, and blog later. Frankly, I don't want to read about your "adventures
in development" until you're done and have something to say about your
(completed) work._

But you have plenty of time to get 12000 karma here?

~~~
edw519
_Did you learn to write by "figuring things out", or did you learn to write
from imitating what you've read?_

By figuring things out. Like I said, this is _my_ experience. I understand
that others' experiences vary, but I have _never_ gotten any benefit from
reading anyone else's code.

 _But you have plenty of time to get 12000 karma here?_

Not even in the same ballpark as blogging. I've been here almost 2 years,
dropping in daily with a few submissions and responses. Doesn't take long for
karma to add up. If I was blogging, OTOH, I'd have to make a major commitment
to make regular high quality submissions. I don't care for irregular or stream
of consciousness blogs. I'd rather just code.

------
shimi
Leave the code for a while, go back home have a rest, dinner, few beers.

Come back tomorrow and sort it...

