I write code primarily in ruby. here are a few things that are different from the norm in my personal coding style.
don’t use the private nor protected keywords in languages
when writing OOP code I avoid using private, protected, or any other keyword
in a language intended to make that method more difficult to invoke. instead I
prefer to adopt a naming scheme to indicate to other users of the code what
parts are intended for public consumption, and what is intended only as
supporting methods for implementation.
the reason I do this is a few reaons
- hiding implementation details generally doesn’t prevent anyone from calling
those methods. most languages that have facilities like a
privatekeyword also have ways of getting around such facilities, which in my view renders them pointless.privateis not a security feature, and in the meantime it makes testingprivatemethods more difficult. I am aware that some people feel that you should not test private methods, but it has been my experience that bugs can just as easily hide inprivatemethods as they do inpublicmethods. so avoiding this extra hurdle makes my job as a developer easier, so it do it. - due to the considerations above, I find the use of
privateto be an overly formal naming convention. I think what golang does (use capitalization to determine what’s public/private) is better, and simpler. - I rarely write code for anyone other than myself or my employer, and even when I publish code for the general public I still follow these rules, because I find them to be simpler overall.
frame problems as data pipeline problems when you can
while I don’t write code in lisp, some of my most used capabilities within ruby
are the methods in the Enumerable
module. I find these so useful
that I will often compose a solution to a programming problem as a series of
steps operating over some kind of collection or list, as one often does in lisp.
use simple data structures rather than custom data structures
if there is no custom behavior to a class, then consider whether it out to be a
struct instead. if a Hash will do the job, but the performance isn’t what
you’d like, consider whether you need that extra performance vs. the simplicity
and practicality of using a Hash or other data structure from the standard
library.
in general, use the standard library when you can, because every bit of effort you put into knowing your core language will be returned back to you in time saved at a rate higher than building your own thing or using custom libraries. but of course this only applies if a custom data structure or library works well.
testing libraries
if I want to use a testing library, I’m generally going to choose a simple assertion-based library. not a huge fan of testing libraries that use English-like phrases to represent program output. I feel that computers are too precise and detailed to work well in this way. if I have to choose between explicit vs. vague I’ll generally choose explicit, even if that means being more verbose.
an example
I wrote a small ruby gem, called
tiny_bus that follows the
style points above. there aren’t any tests, but it’s well documented and works.