- What do you think of this style for getter-putters? - 16 Updates
- What do you think of this style for getter-putters? - 2 Updates
- Debugging a template. I'm stuck! - 2 Updates
- XML Schema to C++ - 1 Update
- Efficient search in std::bitset - 3 Updates
- Onwards and upwards - 1 Update
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Jan 24 08:20PM -0500 DSF wrote: > DSF > "'Later' is the beginning of what's not to be." > D.S. Fiscus When faced with such supposedly "personal taste" choice, I usually try to approach it from the first principles and approach it as a project, from requirements to implementation. Here is how I think about this naming problem: First principle: - Source code's primary and by far most important reason to exist is to be read by humans Requirements: Thus, the main requirement to the source code is to be (human-)readable. In particular a function name role in it is to: - identify a token to a reader as a function name in any context it can be met - give a reader a good idea of what the function does - do the above for a reader as quickly and easy as possible Analysis: - to identify itself as a function *in any context*, a function name should start with a verb - to allow the reader distinguish easily between the two different actions (in your case, getting and setting -- or putting as you call it), the two functions should use different verbs - to do the above for a reader as quickly and easy as possible the naming should use a predominant idiom if exists. In your case, there is a predominant idiom for selecting the verbs, namely get and set, hugely popularized by Java Beans API. An idiom more familiar to C++ users of using attribute name "in pure" for both accessor and modifier does not satisfy the first and second requirements. In addition, it is not a pure idiom as the C/C++-style idiomatic "setters" sometimes return old value and, in other cases, return reference to an object for chaining. Even though your examples does none of it, the code reader will no way of knowing it looking while reading the call site. For the reasons above, I use get/set idiom and avoid C/C++ idiom above. In terms of your original question, I guess I would agree it is "evil". Hope this helps, -Pavel |
| asetofsymbols@gmail.com: Jan 25 07:24AM -0800 Stefan wrote:" << Procedure names should reflect what they do; function names should reflect what they return.« . " This is not right: The function name Should be what that function does in few words ... Eg printf scanf strcpy fopen() [and not FILEpointer()] etc At last I see this in the C library Qsort [not qsorted. ..] etc |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Jan 25 11:42AM -0500 >> In your case, there is a predominant idiom for selecting the verbs, >> namely get and set, hugely popularized by Java Beans API. > We are not part of the Java culture, but of the C culture. I am a part of software engineering culture. I do not think I will ever identify myself as "XYZ language programmer". Selecting the right-for-task level of abstraction is one of the key skills software engineer should possess. Class member name is an abstraction pertinent to multiple programming languages and is best selected at its own merit. > Our guide, therefore, is Rob Pike, not the Java Language > specification. As per the above, I am don't have any sympathy to blind adherence to any programming language-level Bible, be it JLS, K&R, Most Effective Anything or any other thing of the kind. I do appreciate all of the above for good ideas and mean to ignore bad ideas when I see them. I try to distinguish between good and bad ideas based on rationally defined criteria. > semantics. He wrote: > »Procedure names should reflect what they do; > function names should reflect what they return.« So, how is the name for setter like "precision" you are suggesting below reflects what the setter "returns"? You do not seem to follow your own rules. > or > y = getArctan( x/ getSin( t )) > ? calcArctan or calc_arctan would not be bad. Unfortunately, there is no supporting idiom: the predominant idiom for naming math functions is to follow math notation. Math notation was developed for conciseness rather than readability; and there were multiple reasons for that, both rational (to shorten manuscripts that were expensive to produce) and irrational (to hide knowledge from uninitiated). > Thus, setters can be written with »set« as they are > procedures, but getters should just be named after > the value they return as programmers have always done. I am all for following traditions till they don't harm the goal and I do not see following traditions as a worthy goal in itself. As I mentioned earlier, my main requirement to the code is readability. Not indicating in a getter name that it is a getter harms readability in some important contexts. For example, when the code uses getter name in argument to a function or initializer, how will a reader know whether the code refers to data or function member? > A C++ programmer always can follow the style of the > standard library, They can but they do not have to and it is not always a good idea. C++ library design is full of both good and bad ideas. and there we have: |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 25 05:08PM On Sun, 2015-01-25, Pavel wrote: > DSF wrote: ... > First principle: > - Source code's primary and by far most important reason to exist is to > be read by humans I agree. > An idiom more familiar to C++ users of using attribute name "in pure" > for both accessor and modifier does not satisfy the first and second > requirements. Calling them "requirements" make them sound more important that they are. They are criteria you invented. > - identify a token to a reader as a function name in any context it can > be met > - give a reader a good idea of what the function does One problem I have with that is that I don't care about function names: what I care about the full prototype of the function. - Is it a member of some class? Which one? - Is it const? - Is it in some namespace? - What are its arguments? - What is its return type? Just the name isn't enough. I realize (I hope most people do) that the readability matters more at the many places where the function is /called/, compared to where it's defined. Not all of the information I listed is available at the call site, but it's usually enough so you won't have to duplicate knowledge from the prototype into the pure function name. In DSF's case, for example, it's ok, since you cannot easily confuse the setter and the getter: struct Bar { Foo foo() const; // "a Bar object's Foo value" void foo(Foo); // "change the Foo property of a Bar object" }; /Jorgen PS. I also (to my surprise) agree with everything in Stefan Ram's reply -- it probably explains why I think this way. Thank you, Mr Pike! -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Bo Persson <bop@gmb.dk>: Jan 25 06:28PM +0100 On 2015-01-24 22:36, DSF wrote: > If I were to guess, I would say that people have an aversion to > identical names, save for case. > What do you think? I think you should consider what it means to set the left position. Depending on what a foo is, a better function name might be 'move' or 'resize'. Bo Persson |
| asetofsymbols@gmail.com: Jan 25 10:09AM -0800 Pavel wrote:" rationally defined criteria." Rational is not enough... try for see if it is ok... 👌 is enough |
| DSF <notavalid@address.here>: Jan 25 02:30PM -0500 On Sun, 25 Jan 2015 10:39:43 +1300, Ian Collins <ian-news@hotmail.com> wrote: >> void RightPosition(int rpos) {rightposition = rpos;} >> int RightPosition(void) {return rightposition;} >Inverted capitalisation aside, it's fairly common in code I've seen. Inverted capitalization? I've always used mixed case for functions and all lower case for variables. DSF "'Later' is the beginning of what's not to be." D.S. Fiscus |
| Greg Martin <greg.at.softsprocket@dot.com>: Jan 25 07:32PM > right-for-task level of abstraction is one of the key skills software > engineer should possess. Class member name is an abstraction pertinent > to multiple programming languages and is best selected at its own merit. I felt sympathetic to Stephan Ram's point, whether for the same reasons or not I can't say. What I have seen come out of Java, and the elevation of GOF and others, is this strange adherence to priciples that are questionable. It's worth noting that much of that work came out of Smalltalk, a language that by and large collapsed under its own weight - a fate that might resonate with the Java language where there seems to be a great excess of architects running around concerning themselves more with patterns, case and naming conventions then correctness and efficiency. > than readability; and there were multiple reasons for that, both > rational (to shorten manuscripts that were expensive to produce) and > irrational (to hide knowledge from uninitiated). Herein lies the rub; to suggest that arctan in some way is not adequate is to suggest those supporting the software using the functions are inadequate for the task. -- http://www.softsprocket.com |
| Ian Collins <ian-news@hotmail.com>: Jan 26 08:34AM +1300 DSF wrote: >> Inverted capitalisation aside, it's fairly common in code I've seen. > Inverted capitalization? I've always used mixed case for functions > and all lower case for variables. Most coding styles I've used capitalise type names. -- Ian Collins |
| DSF <notavalid@address.here>: Jan 25 02:44PM -0500 On Sat, 24 Jan 2015 16:36:05 -0500, DSF <notavalid@address.here> wrote: > int rightposition; >}; > What do you think? To address two concerns: Const. I assume you mean: int RightPosition(void) const {return rightposition;} since there's no need to mark a return by value as const. These were just quick examples I typed into the newsreader. In actual code, it's const. Void. It is not necessary, but on the other hand causes no problems. Since I'm often dealing with C and C++ code simultaneously (I sometimes need to tweak my libraries written in C and assembly), It adds a clarity for me. Kind of like tagging a derived member of a base class member that's virtual as virtual...it's not necessary, but it adds clarity. DSF "'Later' is the beginning of what's not to be." D.S. Fiscus |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 25 08:40PM On 25/01/2015 19:44, DSF wrote: > adds a clarity for me. Kind of like tagging a derived member of a > base class member that's virtual as virtual...it's not necessary, but > it adds clarity. In this case less is more IMO; I imagine the superfluous (void) will take your brain longer to grok than a simple (). /Flibble |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Jan 25 04:25PM -0500 Ian Collins wrote: >> Inverted capitalization? I've always used mixed case for functions >> and all lower case for variables. > Most coding styles I've used capitalise type names. Just an idea I picked up recently: I used to start all function names with lower-case letter but I saw another style that differed in that the first letter of *free-standing and static* functions names was capitalized and changed to that. I liked it because, as you are reading some non-static member function code and meet some call to another function, it is good to have a clue whether it is another non-static member function of same class (i.e. it implicitly gets the pointer to the whole object) or it is a static member/standalone function that only gets its arguments. -Pavel |
| Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Jan 25 02:41PM -0700 On Sun, 25 Jan 2015 20:40:40 +0000, Mr Flibble >> it adds clarity. >In this case less is more IMO; I imagine the superfluous (void) will >take your brain longer to grok than a simple (). Your brain, perhaps. Mine likes the parentheses separated by something, and I find (void) easier to parse than (). And having evolved to the point where we have words and symbols for concepts like zero and the empty set, () in a function declaration seems like a step backwards. It also seems like a lexical if not semantic return to the ambiguity of the original K&R C function declaration, and I am old enough to remember having to transition from that to ANSI C. Sometimes I miss ALGOL. If you wanted a procedure, you declared a procedure. If it was a typed procedure, you declared a typed procedure. If it didn't have an argument list, you didn't need parentheses at all. But I digress... Louis |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Jan 25 05:25PM -0500 Greg Martin wrote: > Herein lies the rub; to suggest that arctan in some way is not adequate > is to suggest those supporting the software using the functions are > inadequate for the task. Depends on the "task". I defined the task as "readability". BTW I am fully ok with atan (this is the real name, btw, rather than arctan) because it is the only known idiom so anyone who programmed in the domain area will recognize it, regardless of the programming language. BTW I think it is telling that Stephan did not get the function name right even though he is advocating "C/C++" style. Isn't this a live proof that readability matters, sometimes even more so than idioms? -Pavel |
| Greg Martin <greg.at.softsprocket@dot.com>: Jan 25 11:00PM > BTW I think it is telling that Stephan did not get the function name > right even though he is advocating "C/C++" style. Isn't this a live > proof that readability matters, sometimes even more so than idioms? LOL. And I went along with it! The problem with readability, in my POV, is that it depends on who is reading. To someone versed in Lisp it is a very readable language but to someone who isn't it simply seems wrong. If I see a function I'm not familiar with I look up the definition/documentation. -- http://www.softsprocket.com |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Jan 25 06:05PM -0500 Jorgen Grahn wrote: >> requirements. > Calling them "requirements" make them sound more important that they > are. They are criteria you invented. You are certainly correct, all I am saying I take them as requirements. It is fair to argue about whose requirements are better -- but it is only possible after they are explicitly listed by both sides of an argument. > One problem I have with that is that I don't care about function > names: what I care about the full prototype of the function. > - Is it a member of some class? Which one? You might be interested to see my post in response to Ian Collins in this thread about a convention that may give some clue. > - Is it const? getter-setter pattern gives you a good clue, I reckon. At least, you have a fairly good idea that setXxx setter is not const, no? > - Is it in some namespace? > - What are its arguments? > - What is its return type? Don't you sometimes also want to know what the function does? :-) > Just the name isn't enough. I think it depends on the purpose of the reading. If you are looking for a bug, you need all this stuff above. If you want to understand what the code does (e.g. to add a feature or for any other reason) rather than exactly how it maps whatever the author wanted to do to C++, telling function name would certainly be more useful than a prototype of a poorly named function (unless you get a good comment with the prototype but this is probably outside of scope of this discussion). And if you are doing bug-searching etc, such names would not hurt, at the very least. > Foo foo() const; // "a Bar object's Foo value"; > void foo(Foo); // "change the Foo property of a Bar object" > }; You can easily confuse these if the name use is not calling the member but passing its address as an argument to another function call or uses it as a part of an initializer. > PS. I also (to my surprise) agree with everything in Stefan Ram's > reply -- it probably explains why I think this way. Thank you, > Mr Pike! Telling the truth, I did not find any rational arguments in Stefan Ram's post against get/set convention. The principles he quoted from the book are fully satisfied get/set convention. Indeed, getPrecision() reflect "what the function returns" at least as well as precision(). And certainly precision(6) (which should be a "procedure" in Mr. Pike's terms) does *not* reflect *what the procedure does*; in fact, the whole design of iosbase::precision(streamsize) API is bad because it does more than one thing: it is a getter+setter rather than a pure setter, an unfortunate inheritance from early times of C when API leanness trampled readability (and, BTW, performance, too). So I would claim get/set convention satisfies Mr Pike's rules (as cited by Stefan Ram because, I have to admit I did not read the book) better than "pure attribute name for both" convention., too. -Pavel |
| ram@zedat.fu-berlin.de (Stefan Ram): Jan 25 01:37AM >In your case, there is a predominant idiom for selecting the verbs, >namely get and set, hugely popularized by Java Beans API. We are not part of the Java culture, but of the C culture. Our guide, therefore, is Rob Pike, not the Java Language specification. The JLS says: »Method names should be verbs or verb phrases«. But we can see that, using method names such as »main«, »max«, or »sin«, they do not follow their own recommendation! Rob Pike has understood better what governs common semantics. He wrote: »Procedure names should reflect what they do; function names should reflect what they return.« http://www.lysator.liu.se/c/pikestyle.html Do you want to write: y = arctan( x/ sin( t )) or would you prefer: y = calculateArctan( x/ calculateSin( t )) or y = getArctan( x/ getSin( t )) ? Thus, setters can be written with »set« as they are procedures, but getters should just be named after the value they return as programmers have always done. A C++ programmer always can follow the style of the standard library, and there we have: getter: cout.precision(); setter: cout.precision( 12 ); |
| ram@zedat.fu-berlin.de (Stefan Ram): Jan 25 10:49PM >BTW I think it is telling that Stephan did not get the function name >right even though he is advocating "C/C++" style. Isn't this a live Usually, I write the most readable and obvious: arcus = arcus_cuius_tangens_est( tangens ); . |
| DSF <notavalid@address.here>: Jan 25 02:28PM -0500 Hello, group! I have a template class that requires "==" to be overloaded in any class that uses it. If the class doesn't overload "==", I get the compile time message "Illegal structure operation" on the "==" comparison line. This is the error I am receiving. I have gone through the entire project and every class is never used with the template class or has "==" overloaded. If it were a runtime error, I could track down the class involved. But as it stands, I'm stuck! Any ideas on how to track down this error? Thanks, DSF "'Later' is the beginning of what's not to be." D.S. Fiscus |
| Ian Collins <ian-news@hotmail.com>: Jan 26 08:33AM +1300 DSF wrote: > comparison line. This is the error I am receiving. I have gone > through the entire project and every class is never used with the > template class or has "==" overloaded. You need to provide more detail - example code that fails to compile and the exact error message. -- Ian Collins |
| mike myers <mike67440@yahoo.co.uk>: Jan 25 08:29AM -0800 XML processing has turned into a common task that lots of C application designers suffer from. Using low-level XML access APIs for example DOM and SAX is tiresome and error-prone, specifically for large XML vocabularies. XML Data Binding is really a new alternative which automates a lot of the job by showing the data saved in XML like a statically-typed, vocabulary-specific object model. http://www.liquid-technologies.com/xmldatabinding/xml-schema-to-cpp.aspx |
| asetofsymbols@gmail.com: Jan 25 12:19AM -0800 Find a path bit of 8 bit in an array of N bit Example: N == 1000 bit m=1000/32 and n==8 bit Return the index as u32 of array of bits a[] U32 a[m], s=0, limit=m*4; U8 b, *g=a La: for(i=0; i<limit; ++i) if((g[i]&b==b)) return i*8+s; if(s==7) return -1; // not find ShiftDivision(a,1); ++s goto La The same for 16 or 32 or 64 bit if the bit are for example 3 bit 111 one search the char 00000111 |
| asetofsymbols@gmail.com: Jan 25 12:30AM -0800 The above would find one occurrence if exist or modify a little all occurrences Not the first occurrence... |
| asetofsymbols@gmail.com: Jan 25 02:23AM -0800 The above code perhaps would find one occurrence if exist or modify a little all occurrences [as result one array of u32 index] Not the first occurrence only efficiently... Ciao |
| woodbrian77@gmail.com: Jan 24 11:36PM -0800 http://accu.org/index.php/conferences/accu_conference_2015/accu2015_sessions#just_keep_shipping I like his title and agree with this: "There is a customer expectation that the value of the product will improve over time without any effort on their part." Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment