10 things you could be doing to your code right now

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...

>> 9. Read other people’s code

> I have NEVER liked this advice.

The only way I'm able to read code is when I'm actively working towards some goal. Usually this is extending or fixing the existing code in some way. Sometimes it's to extract a specific algorithm or technique for some project of my own. That can certainly be enlightening, whereas just plain reading the code sends me to sleep.

Basically, that turns the advice into:

- either participate in an open source project (bugfixing, implementing features)

- or integrate/convert some complex piece of open source code into/for a project of your own

I definitely think there's something to be gained (learned) from read/write hacking rather than (mostly) write-only. Obviously, if you're trying to get stuff done, all that goes out the window, just get the damn thing written, by whatever means it takes.

Edw519, I agree with you about a lot of things but for this post I disagree with you in several places.

>2. Try out some TDD - Test Drive Development (TDD) makes for better code.

No. Define your target. Code to it. Deploy. Then test.

You're both right. One of the points of tools like RSpec is to make the "define your target" step and the "test" step so close as to be indistinguishable, thus killing two birds with one and a quarter stones.

>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.

It seems like you're just disagreeing to disagree on this one. All the guy is saying is to consider having your tests run on a remote server every time you check in so that you don't break the build. This is hardly radical advice.

>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.

How does automating deployment drudgery like checking out code and SSHing into the production box stop you from knowing your code? As a matter of fact, formalizing this process in a central location probably means you'll know your process better than the development lead who has an intern run deployment off a 12 step list scrawled on a Post-It note stuck to a monitor somewhere.

More importantly, if you're using deployment as a learning exercise, you're doing it wrong.

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.

Same here. I agree fully with using version control, and that reading other code is educational (although being bit hard by having to maintain unforgivably sloppy code you wrote a long time ago will teach you some of the same things, i.e., being neat will make things much easier to fix later), but advice that essentially says, "1. Test, 2. Test, 3. Test, 4. Test, ..." isn't advice, it's a sign that there's something suspicious going on.

I think it's telling that the most noise is made about TDD in the Ruby (and to a lesser extent, Python* ) world, but that it hasn't gotten as strong a foothold in many other languages. TDD seems to me to be a way to take advantage of dynamically-typed languages' strengths while compensating for against their weaknesses, but then it only makes sense with certain kinds of languages / styles of programming, and its advocates seldom seem to address this. (Regression tests are more generally useful, for example.)

Also, contrasting TDD against testing styles from other language-cultures may be enlightening. For example, look at QuickCheck in Haskell: Many tests that could fall under TDD are already covered by the type system in Haskell and ML, so instead it focuses on automatically finding edge cases for you and verifying that invariants hold.

* Also, many testing practices, e.g. TDD, automated unit testing, etc., originated with Smalltalk, another dynamically-typed language.