21–30 of 203 posts
...and another: Use of whitespace (vertical and horizontal) to group and associate code with related parts. Its a trick borrowed from graphic design, but negative-space works really nicely.
I really like the advice from "Perl Best Practices" to code in paragraphs. Sometimes, a large function cannot be broken up usefully, because a lot of state needs to be shared between the different parts, or because the parts don't have a meaning outside of the very specific algorithm. In that case, code in paragraphs: Split the function body into multiple steps, put a blank line between these and, most importantly, a…
Shared state between different parts of the code sounds an awful lot like something that could be a class.
As a junior dev I can confirm the advice about junior devs is very accurate. An anecdote: I recently started working with a team on their half completed web app. They had so many dependencies, and tools for managing dependencies, it took me far longer than it should have to become productive. It's obviously not my place to question which technologies they use, but it can be frustrating.
As a junior dev I can confirm the advice about junior devs is very accurate. An anecdote: I recently started working with a team on their half completed web app. They had so many dependencies, and tools for managing dependencies, it took me far longer than it should have to become productive. It's obviously not my place to question which technologies they use, but it can be frustrating.
It is your place to question everything. Your contribution to the team, even if it comes in the form of perspective alone, is valuable anyway.
I really like the advice from "Perl Best Practices" to code in paragraphs. Sometimes, a large function cannot be broken up usefully, because a lot of state needs to be shared between the different parts, or because the parts don't have a meaning outside of the very specific algorithm. In that case, code in paragraphs: Split the function body into multiple steps, put a blank line between these and, most importantly, a…
I completely disagree, every method can be split in private methods. In that way you don't need awful and unhelpful comments in the middle because you can understand what it does simply from the method name.
I really like the advice from "Perl Best Practices" to code in paragraphs. Sometimes, a large function cannot be broken up usefully, because a lot of state needs to be shared between the different parts, or because the parts don't have a meaning outside of the very specific algorithm. In that case, code in paragraphs: Split the function body into multiple steps, put a blank line between these and, most importantly, a…
I completely disagree, every method can be split in private methods. In that way you don't need awful and unhelpful comments in the middle because you can understand what it does simply from the method name.
> ... a large function cannot be broken up usefully, because a lot of state needs to be shared between the different parts ...
there is no way to break that up with multiple smaller functions without stowing away the state somewhere.
sometimes reading a large function is not half as bad as reading 10 different ones with each altering the shared state.
Earlier quoted context omitted.
It is your place to question everything. Your contribution to the team, even if it comes in the form of perspective alone, is valuable anyway.
I'd go even further and say that newcomers to teams are often the most able to pinpoint essential flaws in the development process.
I'd like to add one: let your tools do the work for you. It may seem like a pain to learn the tooling behind what you do, but once you internalize it, it becomes a superpower. An example is that I use Clojure Refactor Mode (with CIDER) for emacs. A trick (and treat) that a lot of Clojure code uses is the arrow macros: -> and ->>. Clojure Refactor Mode has thread-first, thread-first-all, thread-last, thread-last-all a…
I agree with the tooling part. I tend to prefer the functional version to threading because (1) honestly, like fluent interfaces, it seems overused (2) function application is damn easy to read and (3) as soon as you have as many nested operations, it can and should be refactored into meaningful auxiliary functions. The first line reads as: Multiply all ... 4 copies of ... the length of ... the string "200". So, basi…
(->> (range 10)
(map inc)
(filter even?)
(take 2)) ;=> '(2 4)
(-> {:body {:some {:json :data}}}
(assoc-in [:body :some :more-json] :more-data)
(assoc :status 200)
(update :body json/generate-string))
;;=> {:body "{\"some\":{\"json\":\"data\",\"more-json\":\"more-data\"}}", :status 200}
Earlier quoted context omitted.
It is your place to question everything. Your contribution to the team, even if it comes in the form of perspective alone, is valuable anyway.
I'd go even further and say that newcomers to teams are often the most able to pinpoint essential flaws in the development process.
However, the one-liner example and the chained English-sounding methods, I think might be taken the wrong way. Both can be done well.