Journal Articles
Browse in : |
All
> Journals
> CVu
> 173
(15)
All > Journal Columns > LettersEditor (132) Any of these categories - All of these categories |
Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. If those templates do not exist when you try to preview or display a new article, you'll get this warning :-) Please place your own templates in themes/yourtheme/modules/articles . The templates will get the extension .xt there.
Title: Comments
Author: Administrator
Date: 02 June 2005 05:00:00 +01:00 or Thu, 02 June 2005 05:00:00 +01:00
Summary:
Body:
In the last issue, we published a piece called "Forgetting the ABC by Orjan Westin". It seems that it has sparked something of a conversation on email between Orjan, Herb Sutter and Andrei Alexandrescu.
I've set it out chronologically with to and from set at the start of each email.
Hi,
I know you are both very busy, so I don't really expect a reply to this (although I might try to corner you at the ACCU conference, Herb - what's your favourite beverage?) but I thought you might be interested in the following short article, which was published in the latest edition of CVu, journal of the ACCU.
I just wonder if you have ever thought of what I call the ABC principle?
Hi Orjan, and cc'ing CVu's editor since you said your critique is already published and so he can print this response if he likes.
Thanks for the kind words about C++ Coding Standards. You also wrote:
What did surprise me was an omission. [...] I just wish they hadn't missed what I have always thought of as the ABC principle - Always Be Conventional. To be fair, it is covered, albeit in a couple of specific instances.
Items 26 (Preserve natural semantics for overloaded operators), 27 and 28 (Prefer the canonical form[s of +, +=,++, and the minus equivalents]) and 55 (Prefer the canonical form of assignment) are all expressions of ABC.
However, while it is important to follow the principle when dealing with operators, I was surprised that there was no generalisation of it, since it is a common problem anywhere an established convention exists. To be fair, I think you've just overlooked the very first Item 0. :-) Also Item 6. ABC is basic wisdom and common sense, just like KISS, and it bears repeating. While Sutter and Alexandrescu devote four out of one hundred and one items to special cases, they fail to point out the underlying general principle. I do not know whether this was through oversight or because they considered it too obvious, but personally, I feel it is an important principle that is neglected too often.
It is important; that's why we deliberately wrote the opening Item 0 with the repeated mantra of being "consistent" (FWIW I think in this context that's a better word than "conventional"). Here are some specific examples, including seven quotes from that Item where the word is used explicitly:
-
general formatting ("Do use consistent formatting", "be consistent with the style already in use")
-
indenting ("Use any number of spaces you like to indent, but be consistent")
-
naming variables, as in your first example ("do use a consistent naming convention" and "do use consistent and meaningful names and follow a file's or module's convention")
-
brace placement ("be consistent: Don't just place braces randomly or in a way that obscures scope nesting, and try to follow the style already in use in each file")
-
spaces/tabs ("be consistent: If you do allow tabs, ensure it is never at the cost of code clarity and readability and readability as team members maintain each other's code (see Item 6)")
That's all in the first two pages. Note also that this overlaps with the important theme of Item 6, which covers your other examples. Your article's summary said:
It's just a matter of following conventions where they exist, fulfilling expectations and avoiding putting in surprises for other developers (or oneself, in six months time).
That sure sounds a lot like our Item 6's opening Discussion paragraph:
"Your code's maintainer will thank you for making it understandable - and often that will be your future self, trying to remember what you were thinking six months ago."
Hmm. :-)
If you look again, I think you'll find we're in violent agreement that consistency is important. Thanks for writing, and best wishes,
I concur with Herb, and I'd like to add a paradox that I find funny: Orjan's statement is not congruent with itself.
That is, throughout his discussion he implies "Always Be Conventional" aka ABC as a universal, valid, known, beaten-to-death principle ("ABC is basic wisdom and common sense, just like KISS, and it bears repeating").
Yet, a google search for the phrase "Always be Conventional" yields 68 results, zero of which have anything to do with programming. A search for "Always be Conventional" and "ABC" yields two results, none of which are related to programming, and none of which even mentions ABC as an abbreviation of "Always be Conventional" (or "Always be Consistent" for that matter).
So why is the statement not congruent with itself? Because if the statement were conventional, it would obey to whatever established conventions are out there, and "Always be Conventional"/ABC is simply not out there.
As such, some statements in the short article are simply untrue representing author's thinking and not generally accepted views, as the writing however states quite explicitly. Nothing personal, but I suggest CVu changes the article, pulls it off, or publishes a correction in a future issue.
I concur with Herb, and I'd like to add a paradox that I find funny: Orjan's statement is not congruent with itself.
I, too, am sometimes amused by displays of incongruency. For instance, here you agree with Herb who said, if I may paraphrase, "It is important and you are saying the same thing as we do", and then you ask for the article to be pulled. I chose to be amused, rather than offended, since you do say it's not meant personally.
That is, throughout his discussion he implies "Always Be Conventional" aka ABC as a universal, valid, known, beaten-to-death principle ("ABC is basic wisdom and common sense, just like KISS, and it bears repeating").
There is an expression that goes "the map is not the world". It may be worth thinking about this.
Yet, a google search for the phrase "Always be Conventional" yields 68 results, zero of which have anything to do with programming. A search for "Always be Conventional" and "ABC" yields two results, none of which are related to programming, and none of which even mentions ABC as an abbreviation of "Always be Conventional" (or "Always be Consistent" for that matter).
I am not surprised. When presenting what I was going to write about, I used the phrase "what I have always thought of as the ABC principle - Always Be Conventional". I say at the beginning of the article that this is MY name for it. Now, had I been an influential writer who had been hammering this phrase for years, it might possibly have become a common name, but I am not, I haven't and and it isn't.
It's my name for a principle, because as far as I am aware it has no established name. One specific instance of it has been summarised by Scott Meyers as "When in doubt, do what ints do", but that is a specialization and I wanted to talk about it in a wider scope.
Having introduced my name for it, I then went on to illustrate what I meant with some examples. Obviously I have failed to delineate precisely what the seemingly offending phrase meant to me, but I'll come back to that.
So why is the statement not congruent with itself? Because if the tatement were conventional, it would obey to whatever established conventions are out there, and "Always be Conventional"/ABC is simply not out there.
I humbly ask that you consider the notion that the principle of which I wrote may be well established, general, basic, well known, and important. I doubt that you have any objections to that notion, since you say you concur with Herb that it is important, and you did spend four items focusing on specializations of it in your book.
It is possible that the phrase I used was unclear - English is not my first language and there might be nuances I am not aware of that makes it say something different from what I wanted to express - and I would be happy to write a clarification if asked to do so.
I imagine that for clarity's sake I should have said that "This principle is basic wisdom..." rather than use MY name for it, but since I had both established that this name was something that I personally use as a shorthand for the principle, and (to the best of my ability) illustrated what I meant with "ABC", I thought it would be clear what I spoke about. That it was not is now obvious, and I apologise for my failure. However...
As such, some statements in the short article are simply untrue representing author's thinking and not generally accepted views, as the writing however states quite explicitly.
What statements are untrue? You imply, it seems to me, that I have wilfully lied and I can't say I am happy about that. I am astonished that you have spent a lot of effort disproving something I have never said, and that you think this warrants pulling the article.
You may, if you wish, contend that the principle is false, unknown or not a generally accepted view. That, at least, would be in reply to something I said. If so, I would happily argue my case, because I believe it is true whatever label is used to refer to it. Not knowing any other, I used my own. That I am the only one using that label has no impact on the validity of the principle to which it refers.
In honesty, though, I have always thought of the principle using a phrase in Swedish, which can be literally translated as "Follow Established Conventions" - something I told the editor in my cover notes. This is clearer and less ambigious, I admit, but given that I think it is a basic principle, and that it could be translated to give the acronym "ABC", I gave in to the temptation to get a title that would, I hoped, express the basic nature of the subject.
As for your Items 0 and 6, I have read them, but I do not think they cover what I was looking for. They are (especially Item 0) at a higher level of generalisation, while the other items I refer to are at a lower one.
In the examples I gave, I was concerned with interfaces, and what established conventions have led programmers assume and expect. I expect things to work in a way reminiscent of similar things. In a container with a STL-style interface, I expect the function "empty" to return a bool and not mess with the data. One could argue that it should do the same thing as "clear" and one could win that argument on all points except one: the convention established by the STL is that is should tell whether the container is empty or not.
These are the kind of conventions I argue one should be aware of and adhere to, and while Item 6 touches on it, I, personally, would have liked an explicit mention of the importance of doing the expected and assumed. It would certainly have been helpful to me thirteen years ago, when I first began working with C++. That is just my personal opinion, though, and I will continue to recommend the book to all C++ programmers I meet.
Sorry, I choose to stand by my words. Sorry about the stir that my previous reply has caused. I do think that "Always be conventional" is applicable because it's overly general, but so is NDSSATYWNBAOWYD, which is the self-evident advice that my mom jokingly gives me: "Never Do Something Shameful, And Then You Will Never Be Ashamed Of What You Did". Does it apply to programming? Sure. Could I find examples that back it up? Definitely. Could I say "NDSSATYWNBAOWYD is basic wisdom and common sense, just like KISS, and it bears repeating"? No way.
That's where my axe to grind is: comparing ABC with KISS implies that googling for "Keep it Simple, Stupid" would reveal comparable ubiquity with "Always be conventional", and "repeating" means it has been said many times by many people before, which it simply hasn't.
And that's where the discourse ended. So much said over such a small article.
As always, if you have anything to say about the content, please feel free to get in touch.
Notes:
More fields may be available via dynamicdata ..