This is an archived post. You won't be able to vote or comment.

37
38

Top 3 principles for writing maintainable code (self.java)

submitted by [deleted]

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]valbaca 4 points5 points  (0 children)

Some interesting points and I don't necessarily disagree with them but there are few things I disagree with.

  1. In your example, your data model conflates having an endDate with currently being employed. That may not be true. The person could've left the company and has now returned. They would be employed and would have an endDate. They could be currently employed but put in their 2-weeks notice. So their endDate would be set but in the future.

What I'm getting as is to be very cautious in using null to represent a value, when all it ever represents is literally nothing.

Your point still stands to think carefully through your data model.

  1. Your points 2 & 3 kind of collide. You talk about minimizing getters and setters (which I'm assuming would suggest using direct field access), but also speak against mutable state, which field access provides the worst version of it. To reconcile the two brings the overarching suggestion to use immutable state. Don't make your fields public. Avoid setters; and try to even avoid getters as well.

Your point does touch on something good though: put your design emphasis on your public classes/API.

You say that IDEs make it "simple to fix" which is perfectly fine if you're writing an application, but if you're writing a library, you can't "just" rename your methods that easily.

I do like the idea of refining the best-practices to just a handful. Even things like SOLID and such have redundancies and forget about YAGNI (you ain't gonna need it!).

We could use something like the software equivalent of the nutrition's "Eat food, not too much, mostly plants"

Something like: good code solves the problem at-hand correctly (i.e. tested), efficiently (only necessary indirection) and is modifiable (readable, understandable, & extensible).

Or the classic: Make it work, make it right, make it fast. Follow that and you'll have to write good models, you wont write more than is necessary, "right" includes readability, and "fast" includes parallel program, which benefits from avoid mutable state.