Recently, while working for one of my clients on someone other's code I spotted the following definitions of members in some class:

Why I do not like it, you might ask? Well, I'm lazy and commenting each declaration seems like too much work... You might ask 'why?' again - well, if I would like to add some definition to this code, I'd have to write a comment as well in order to maintain the (arguably flawed) coding style! I'm only a service provider for my client and wouldn't like to break this code's look and feel.
As you might know I'm not a friend of the newfangled "no comments" politics, but this is an example where we could definitevely use some of it. But why's that so bad again? It's because you could fix the example code with careful usage of naming* and it's even not that difficult!
Let's have a go at it:
1 | /* State m_state => */ State m_dateValidity; |
here we don't have to include "state" in the name, as it is already stated as the domain of the variable.
1 | /* QAction* m_action => */ QAction* m_datePickerPopupAction; |
1 | /* QDate m_date => */ QDate m_parsedDate; |
1 | /* QStringList m_parseFormats => */ QStringList m_dateParsingFormats; |
1 | /* bool m_twoYearIsPast => */ bool m_treat2DigitYearsAsPast; |
1 | /* QDate m_minDate => */ QDate m_earliestDate; |
1 | /* QDate m_maxDate => */ QDate m_latestDate; |
1 | /* bool m_justFocused => */ bool m_focusReceived; // used for workaround ABC... |
So, what do you say? It wasn't even that difficult. Arguably the result isn't perfect but it's a lot better than the original. Maybe it's even good enough?
So watch your names, they are important - because code readibility is important!
--
* As they say -"there are only 2 hard problem in comp. sci. - cache invalidation and naming things"...
No comments:
Post a Comment