"The Elements of Style", by Strunk & White. 92 pages. For example, page 19: "Put statements in positive form." Code is improved if booleans are put in positive form, such as replace: if (!featureIsDisabled()) ... with: if (hasFeature()) ... You might laugh, but I see the first form all the time. Sometimes I go on a refactoring mission to remove as many negations, nots, and bangs from the code as possible.
I use negative flags (but not negations) so that I can break out early with early returns ...
if (isFeatureDisabled()) {
// do not proceed
return
}
But still the style guide holds, since there is no negations ...
I see only positive reviews for this book here, but I went to look it up on amazon and the first review doesn't look particularly good and I'm looking for anyones reason to refute this: "This book does not consider functional programming, or the fact that terrible software in modern times is often the result of layers of incorrect abstraction that are often induced by the overuse of "object oriented" (OO) programming…
I would not agree that the bias towards OOP is a problem in the book, since most of the concepts are paradigm-agnostic. Nevertheless, I feel that the author exposes a rather opinionated (sometimes even dogmatic) and narrow view of software design. Although I think that the book provides a lot of very valuable insights, I missed a more differentiated view of the concepts presented in the book. For example, in chapter…
I've also noticed that point in one of his talks and disagreed with it immediately. My own experiences have found small components easier to test and reason about in higher level components. I do think that navigating through a codebase with a lot of small files would make the codebase seem a lot more complex (especially without a modern code editor where you can't do things like click on an interface method and see all its implementations), but the biggest drawback of having small components, in my opinion, is that a lot of the developers I've observed are very bad at drawing coherent software boundaries
A Philosophy of Software Design. Very well-written. At 190 pages, quite likely finish-able in a weekend. But if you get 70% of the way through it, that is still very valuable. It makes sense as an underlying set of principles that explain why you would use design patterns.
I don't find design patterns very compelling unless you're stuck with underpowered statically-typed languages like Java. There, they serve somewhat as a way out of the straight jacket. In more powerful languages there are better, simpler ways to design your systems.
I see only positive reviews for this book here, but I went to look it up on amazon and the first review doesn't look particularly good and I'm looking for anyones reason to refute this: "This book does not consider functional programming, or the fact that terrible software in modern times is often the result of layers of incorrect abstraction that are often induced by the overuse of "object oriented" (OO) programming…
I would not agree that the bias towards OOP is a problem in the book, since most of the concepts are paradigm-agnostic. Nevertheless, I feel that the author exposes a rather opinionated (sometimes even dogmatic) and narrow view of software design. Although I think that the book provides a lot of very valuable insights, I missed a more differentiated view of the concepts presented in the book. For example, in chapter…
Refactoring UI. Very pragmatic and approachable for us developers who may not have much idea about design. If you want 'good enough' design for your side project but don't want to use templates, this is the book you'd want to read. The book is a bit expensive though.
"The Elements of Style", by Strunk & White. 92 pages. For example, page 19: "Put statements in positive form." Code is improved if booleans are put in positive form, such as replace: if (!featureIsDisabled()) ... with: if (hasFeature()) ... You might laugh, but I see the first form all the time. Sometimes I go on a refactoring mission to remove as many negations, nots, and bangs from the code as possible.
?? You mean this book-- "The Elements of Style is an American English writing style guide in numerous editions. The original was composed by William Strunk Jr. in 1918, and published by Harcourt in 1920..." [1] Cool! 1920s book on English writing style inspiring your coding style. My first reaction to the 'positive form' was to recall a conversation I had once with a retired programmer about flow control diagrams. Th…
> 1920s book on English writing style inspiring your coding style.
Absolutely. It is surprising (but not really once you think about it) how applicable it is.
"The Elements of Style", by Strunk & White. 92 pages. For example, page 19: "Put statements in positive form." Code is improved if booleans are put in positive form, such as replace: if (!featureIsDisabled()) ... with: if (hasFeature()) ... You might laugh, but I see the first form all the time. Sometimes I go on a refactoring mission to remove as many negations, nots, and bangs from the code as possible.
I use negative flags (but not negations) so that I can break out early with early returns ... if (isFeatureDisabled()) { // do not proceed return } But still the style guide holds, since there is no negations ...
I do try to reframe as different words, such as "right" instead of "notLeft", to eliminate negations.
I would not agree that the bias towards OOP is a problem in the book, since most of the concepts are paradigm-agnostic. Nevertheless, I feel that the author exposes a rather opinionated (sometimes even dogmatic) and narrow view of software design. Although I think that the book provides a lot of very valuable insights, I missed a more differentiated view of the concepts presented in the book. For example, in chapter…
I've also noticed that point in one of his talks and disagreed with it immediately. My own experiences have found small components easier to test and reason about in higher level components. I do think that navigating through a codebase with a lot of small files would make the codebase seem a lot more complex (especially without a modern code editor where you can't do things like click on an interface method and see…
> a lot of the developers I've observed are very bad at drawing coherent software boundaries
That's a very good point. Designing small components probably requires more effort and can also cause a lot of harm if done incorrectly.
I would not agree that the bias towards OOP is a problem in the book, since most of the concepts are paradigm-agnostic. Nevertheless, I feel that the author exposes a rather opinionated (sometimes even dogmatic) and narrow view of software design. Although I think that the book provides a lot of very valuable insights, I missed a more differentiated view of the concepts presented in the book. For example, in chapter…
When arguing against small classes and methods by default, he's in good company: http://number-none.com/blow/john_carmack_on_inlined_code.htm... Prior HN discussion: https://news.ycombinator.com/item?id=12120752
There are also numerous people which promote the excessive use of small classes and methods like for example Kent Beck or Robert Martin.
As always, there probably is no "right" answer, it really depends on context.
For those of you who claim to start and finish a book in a weekend, are you spending literally the entire weekend doing nothing by reading? Do you take breaks? Do you speed read? Do you take notes? What's your strategy?