Fork me on GitHub
#clojure-uk
<
2016-10-17
>
agile_geek07:10:22

@paulspencerwilliams One word answer "readability"! Longer answer: Developers spend most of their time reading and comprehending code, often written by someone else. Readability is very subjective but you can do so much in 3 lines of Clojure I would favour small fns

agile_geek08:10:21

@paulspencerwilliams I agree about too many small fns to some extent but I think the really hard thing to do in Clojure (or any other lang) is to decide on what namespaces do (SRP). Get this right and I think the number of fn's takes care of itself. P.S. you'll never finish refactoring NS and adding more until your s/w end of lifes

korny08:10:31

@paulspencerwilliams strongly in favour of splitting here. Not just for testability (though that’s a side benefit) nor for reusability (though it’s good to DRY up code) - but for expressiveness - any function that is over a screen long is likely to be too hard to understand for a new pair of eyes.

malcolmsparks10:10:48

@paulspencerwilliams I'm rather ambivalent about function size. In my view it's not necessarily easier to reason about a ns with lots of small functions, given the increased indirection that entails. But I do believe functions should do one thing. Call me a heretic but I think the argument for testability involves design trade-offs which can actually harm good design.

paulspencerwilliams10:10:09

@korny haha, over a screen length! It’s all about norms. To me, a large function is around 10 - 15 LoC

malcolmsparks10:10:48

I prefer well designed regression tests, coarse enought to make function size irrelevant.

malcolmsparks10:10:38

You can write an entire web API in one function. I'm not persuaded that doing so is 'wrong' on the basis of function size alone.

korny10:10:39

@paulspencerwilliams sorry, I should have included the context that I’m working on a 13” macbook 🙂 So in my current font “screen length” is 28 lines (repl takes up 1/3 of the screen)

korny10:10:11

I’d agree that 10-15 lines is about my comfort zone, but I wouldn’t say “oh my god that’s horrible” until I got to 25 lines or so. I’d probably split before then because of other reasons - it’s hard to have a function that does just one thing that’s 25 lines long.

korny10:10:38

There are obvious exceptions though - especially when the line gets blurred between code and configuration. If it’s really config not code, then a whole lot of other rules apply.

korny10:10:33

(I’m saying this because I’m setting up some restful routes, which is way beyond a screenful at the moment 😉 )

glenjamin10:10:54

"does it fit in your head?” rather subjective, but tends to fit IME

agile_geek11:10:24

@malcolmsparks I'd agree with the fns do one thing but due to the expressiveness that generally that means they're smaller. However it all depends on what you think is "one [atomic] thing"

dominicm11:10:12

I think maps make the line count harder. I try to keep my functions short, but if they're creating maps throughout that process, they tend to gain 5loc just from the map.

agile_geek11:10:55

@dominicm yeah I think the moral is not the LOC as this is irrelevant but how easily parsed by a developer. So I can parse a Java method of 30 LOC easily but 30 LOC on Clojure is more dense.

malcolmsparks11:10:40

@agile_geek I don't agree, I think the LOC is actually irrelevant. It may correlate that more easily understood code happens to have smaller functions, but it doesn't follow that reducing the size of functions makes code more easily understood.

agile_geek11:10:54

@malcolmsparks I obviously didn't express myself well. I also think LOC are irrelevant

mccraigmccraig11:10:56

@korny wow - 28*3/2=42 lines of screen 😞 i get 79 lines of code in emacs on my mbpr15... i wonder if we therefore have very different sensitivities about what is 'long' ?

agile_geek11:10:37

@malcolmsparks it's more the complexity "factor". So I agree about one thing but frequently you can break things down into smaller and smaller "one things"

agile_geek11:10:03

Not always a good thing if you go to far

dominicm11:10:16

is number of operations/branches a better measure?

agile_geek11:10:25

@dominicm good old Cyclomatic complexity?

dominicm11:10:19

@agile_geek apparently! Didn't know that term before.

agile_geek11:10:20

@dominicm it's one simple way I've used for many years to manage this problem in Java

korny11:10:40

@mccraigmccraig if I need more context I maximise the editor window or shrink the font or both. Or if available, plug in to an external monitor.

agile_geek11:10:42

Lots of code linting for it in Java space

korny11:10:08

@mccraigmccraig also I keep the font big because I’m getting old and tiny fonts tire my eyes 🙂

dominicm11:10:34

@korny alternatively create multiple splits on the buffer. Then you can view the different scopes separate to the part you're figuring out. Do this a lot on my laptop

dominicm11:10:47

@agile_geek Do you find it an accurate measure?

korny11:10:00

I like using cyclomatic complexity as a metric, but haven’t found good tools to measure it consistently in all languages - especially clojure 🙂

glenjamin11:10:09

is it a proper measure, or a proxy measure?

malcolmsparks11:10:34

There is a downside to lots of small functions which stops me a embracing them wholeheartedly, and that is the naming problem - all these functions need to be named, that's often cognitively taxing when programming, and you can end with all these bullshit functions with bullshit names that give the illusion of 're-usability' but in reality are far too tied to their domain to be generally useful. And there's also the problem that once you have a small (public) function, some other ns can 're-use' it and then you've created a coupling you didn't expect. For that reason I think the DRY principle is hugely over-valued (and this point was very well made in the original article: https://medium.com/@rdsubhas/10-modern-software-engineering-mistakes-bc67fbef4fc8#.txrola3hf - which is well worth a read imo)

glenjamin11:10:24

I almost never write small functions for re-usability reasons

glenjamin11:10:29

it’s usually cognitive

agile_geek11:10:20

@dominicm it's a pretty good indication

agile_geek12:10:00

@malcolmsparks I'd agree about the naming problem. It's another indicator, similar to is it easily testable, to use. As with all these things it's just another 'tool' to use to decide on how to organise your code.