Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

10 things you could be doing to your code right now

smartic.us

Post reply on HN
Print view View original

11–18 of 18 posts

Re: 10 things you could be doing to your code right now

#11

Post by zenspider »

ivey wrote: post #5
zenspider wrote: post #2

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) Rub…

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

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

Re: 10 things you could be doing to your code right now

#13

Post by orib »

ScottWhigham wrote: post #7
edw519 wrote: post #3

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 re…

It's a lot easier to test once you have something to test. Test time is the time for testing No offense but these comments show us that you aren't aware of what TDD really is. I'm not coming down on you but I think that, if you are going to offer advice and critique on the guy's post, you should at least have knowledge of the topics.

Or (I can't speak for him, but this is what I took away from it) is that he doesn't believe in test driven development. For what it's worth, I think elements of it are nice, but it's often taken too far.

Re: 10 things you could be doing to your code right now

#14

Post by silentbicycle »

pmjordan wrote: post #4
edw519 wrote: post #3

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 re…

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

Definitely. Reading other people's code is great advice in the long term (like, Norvig's "Teach Yourself Programming in Ten Years" long term), but you generally need to put some real time into it before it becomes rewarding, so it generally isn't very helpful when a deadline or sudden bug is the problem.

Re: 10 things you could be doing to your code right now

#15

Post by jrockway »

edw519 wrote: post #3

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 re…

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?

Re: 10 things you could be doing to your code right now

#16

Post by edw519 »

jrockway wrote: post #15
edw519 wrote: post #3

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 re…

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) an…

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.

Re: 10 things you could be doing to your code right now

#17

Post by edw519 »

silentbicycle wrote: post #10
edw519 wrote: post #3

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 re…

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…

...it's a sign that there's something suspicious going on...

Thank you, silentbicycle. That's what I was trying to say, but you said it much more eloquently than me.

I have always looked at "tools" with a wary eye. Are they really a solution to an existing problem or are they aspirin (or a crutch) for a pain without addressing the underlying cause. I realize many people believe the former. I usually believe the latter. They don't call me a caveman coder for nothing.

Re: 10 things you could be doing to your code right now

#18

Post by silentbicycle »

edw519 wrote: post #17
silentbicycle wrote: post #10

Earlier quoted context omitted.

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…

...it's a sign that there's something suspicious going on... Thank you, silentbicycle. That's what I was trying to say, but you said it much more eloquently than me. I have always looked at "tools" with a wary eye. Are they really a solution to an existing problem or are they aspirin (or a crutch) for a pain without addressing the underlying cause. I realize many people believe the former. I usually believe the latte…

Ruby people praising TDD is like hearing Java people blown away by Design Patterns or C people talk about techniques for avoiding buffer overflow errors: Sure, it's a good thing that they're trying to improve the quality of their software, but to some extent their methodologies are compensating for tradeoffs (and sometimes just flaws) in those languages. The trick is telling when they're genuinely useful techniques from when they're solving problems that could have been avoided entirely.

I don't think that all tools are bad, though; far from it. Just, sometimes it's better to address the root causes of problems, rather than symptoms. (Almost always better, in the long term, but deadlines happen.)

I'm working on a tool right now (not ready to share yet, it's a rare spare time project), working title "dehydrator" (like the DRY principle and hydras, dragons that keep growing more heads) which can scan code (or arbitrary sequences of tokens, really; it's an OCaml functor) and report on heavily duplicated patterns it finds. The motive is to help reintegrate code that has been copied-and-pasted to several places with only small changes. Obviously, the solution is Don't do that!, but the world is full of projects that already have years of cruft.

Post reply on HN