Re: renamepalooza time
On 22/01/2011 00:16, Andrei Alexandrescu wrote: Ever since I worked with STL, I fell in love with names_with_underscores. I can't explain it, but my feeling is that code using that convention is calm and levelheaded. The explanation for that could very well be some form of Pavlovian reinforcement/conditioning. :) -- Bruno Medeiros - Software Engineer
Re: renamepalooza time
Am 04.02.2011 15:11, schrieb Bruno Medeiros: On 22/01/2011 00:16, Andrei Alexandrescu wrote: Ever since I worked with STL, I fell in love with names_with_underscores. I can't explain it, but my feeling is that code using that convention is calm and levelheaded. The explanation for that could very well be some form of Pavlovian reinforcement/conditioning. :) I would say it's the Stockholm syndrom :) Mafi
Re: renamepalooza time
spir wrote: On 01/23/2011 12:03 AM, Ali Çehreli wrote: Sounds similar to using whitespace for visual grouping like in a*b + c*d or [ [1,2,3] , [4,5,6] ] But may be a bit too complicated for a public, free-willing, style, don't you think? Rather for an enforced project or corporate one, I'd say... Agreed, but I will keep using an underscore after is. Another reason why I do so is, when used with camelcase, that little is capitalizes the next word just to be consistent with the camelcase part of the naming conventions. When we have an attribute of an object named 'ready', 'isReady()' doesn't match because 'ready' doesn't match 'Ready'. An underscore makes it stay lowercased: is_ready(); The attribute can follow the camelcase rule and be consistent with the rest of the names: is_lastItem(); Ali
Re: renamepalooza time
On 01/23/2011 09:13 AM, Ali Çehreli wrote: Agreed, but I will keep using an underscore after is. Another reason why I do so is, when used with camelcase, that little is capitalizes the next word just to be consistent with the camelcase part of the naming conventions. When we have an attribute of an object named 'ready', 'isReady()' doesn't match because 'ready' doesn't match 'Ready'. An underscore makes it stay lowercased: is_ready(); The attribute can follow the camelcase rule and be consistent with the rest of the names: is_lastItem(); You're right, it's a nice convention. Deins -- _ vita es estrany spir.wikidot.com
Re: renamepalooza time
On 2011-01-21, Jonathan M Davis jmdavisp...@gmx.com wrote: tr? The name means nothing to me. I haven't a clue where the name comes from, so I can't really give a better version of the same name. As it is, tr seems fine to me, particularly since tR just seems stupid. It should probably get a more descriptive name though. replaceChars? Just for everyone's info. tr is a standard unix command; been around forever, and it is a mnemonic for 'translate'. It's also in perl. tr A-Z a-z # convert to lower-case Perl: $ph =~ tr/0-9/cd # get only the digits from a phone number entry field.
Re: renamepalooza time
On Sunday 23 January 2011 07:12:16 Brad wrote: On 2011-01-21, Jonathan M Davis jmdavisp...@gmx.com wrote: tr? The name means nothing to me. I haven't a clue where the name comes from, so I can't really give a better version of the same name. As it is, tr seems fine to me, particularly since tR just seems stupid. It should probably get a more descriptive name though. replaceChars? Just for everyone's info. tr is a standard unix command; been around forever, and it is a mnemonic for 'translate'. It's also in perl. tr A-Z a-z # convert to lower-case Perl: $ph =~ tr/0-9/cd # get only the digits from a phone number entry field. Good to know. I know a number of unix/linux commands, but there always seems to be more of them... Not that that's a bad thing. - Jonathan M Davis
Re: renamepalooza time
Jonathan M Davis wrote: On Friday, January 21, 2011 06:04:53 spir wrote: On 01/21/2011 09:44 AM, Jonathan M Davis wrote: Well, entab, I'd argue_does_ follow the naming convention, because entab would be a verb, albeit a made up one. Certainly, en is a prefix, not another word, so I think that entab is fine. If that doesn't fly, then go with enTab, I guess, but I'd argue that entab is a single word and fine as it is. I fully agree with you on the linguistic side: entab is a single-word term, just like eg input (no-one would suggest inPut ;-). But practically, the decomposition enTab helps understanding this identifier by nicely highlighting tab, don't you think? This is even more relevant for foreigners, who have here to guess: (1) that entab is not a 'normal' english single-word term they would just not know (2) as you say, that en- is a verb-forming prefix in english one can more or less freely use. Non-trivial. I'm afraid that I don't agree at all. enTab is hideous and arguably confusing precisely because en is _not_ a word. I'd start trying to figure out what en was short for if I saw an enTab function. entab is _far_ clearer. Would you make a function named enClose? I should hope not. Granted, enclose is actually a word that you'll find in a dictionary, but en is a normal prefix in English, and trying to treat it as a word or abbrevation in function names would just be confusing. - Jonathan M Davis Even worse -- 'en' _is_ a word! (From typography, with 'en' and 'em'). It could mean a narrow tab, in contrast to an emTab, which would be a wide tab... It's unfortunate that the dominant language for programming is the one with by far the worst spelling.
Re: renamepalooza time
Ever since I worked with STL, I fell in love with names_with_underscores. I can't explain it, but my feeling is that code using that convention is calm and levelheaded. Camel case forces me to think of one-word names because at the second word some beauty is already lost; never felt the same with the underscores. If I could go back in time I'd propose that convention throughout. Agree on every bit! Silly me, i was thinking you are one of those (or the one) that enforce camelCase!
Re: renamepalooza time
On 22.01.2011 01:36, Sean Kelly wrote: Andrei Alexandrescu Wrote: Ever since I worked with STL, I fell in love with names_with_underscores. I can't explain it, but my feeling is that code using that convention is calm and levelheaded. Camel case forces me to think of one-word names because at the second word some beauty is already lost; never felt the same with the underscores. I like the look of the STL convention, but overall prefer that Camel case distinguishes between types and values. It completely eliminates the need for a _type suffix in STL-style typedefs, for one. No problem: Some_type some_variable I haven't actually used this style personally. I've just noticed that it's the style used throughout Stroustrup's latest book (Programming). Seems like the obvious next step for the underscore style of naming.
Re: renamepalooza time
On 22/01/11 10:55, bearophile wrote: I think variable names in camelcase are less noisy. Sorry, I meant: I think variable names in camelcase are more noisy. Bye, bearophile I think youAre probablyRight (that camelCase is moreNoisy) but unfortunately yourArgument foundered beCause of a typoMistake. :-) Justin
Re: renamepalooza time
On Fri, 21 Jan 2011 18:16:20 -0600, Andrei Alexandrescu wrote: Ever since I worked with STL, I fell in love with names_with_underscores. I can't explain it, but my feeling is that code using that convention is calm and levelheaded. Camel case forces me to think of one-word names because at the second word some beauty is already lost; never felt the same with the underscores. If I could go back in time I'd propose that convention throughout. Andrei Hehe. This the one only case I'm happy we can't turn back the time ;) For me camelCase is *much* more beautiful than underscores. When reading STL code my eyes coupled with brain have difficulties with instant distinction where the name exactly starts and ends (thanks to intention of simulating spaces). PS. One worders are the best, of course. Cheers Piotrek
Re: renamepalooza time
On 01/22/2011 02:16 AM, Andrei Alexandrescu wrote: On 1/21/11 4:49 PM, Jonathan M Davis wrote: On Friday, January 21, 2011 13:30:11 Ali Çehreli wrote: Andrei Alexandrescu wrote: iswhite I like separating is with an underscore, like most coding styles do: is_whitespace Warm and fuzzy... :) Most? I've never dealt with a coding style that had underscores. It's generally camelcase, though I get the impression that using underscores in C code is more common (I've mostly used C++ and Java). Regardless however, Phobos' coding style uses camelcase, not underscores. And this whole thread was started to try and find better names for functions which need new names, because they don't currently follow Phobos' naming conventions. Ever since I worked with STL, I fell in love with names_with_underscores. I can't explain it, but my feeling is that code using that convention is calm and levelheaded. Camel case forces me to think of one-word names because at the second word some beauty is already lost; never felt the same with the underscores. If I could go back in time I'd propose that convention throughout. Andrei My problem with underscore-delimited identifiers is that they can get really hard on eyes: int my_temp_var = some_object_instance.some_field.some_other_field; The dots are completely lost. Also, when identifiers are getting long (and in large libraries they tend to) the underscores become to look pretty annoying. I have worked with many conventions and camelCase remains my favorite for now.
Re: renamepalooza time
My two cents. (Incidentally, when I learned to type -- in the USA in 1970 -- a cents symbol was standard on the keyboard. Shift-2 or Shift-6, I think.) Jacob Carlborg Wrote: LS - lineSeparator/LineSeparator PS - paragraphSeparator/ParagraphSeparator These are established acronyms: (http://www.unicode.org/standard/reports/tr13/tr13-5.html). I would leave them as is. entab - entab/spacesToTabs expandtabs - expandTabs/tabsToSpaces I prefer the more explicit spacesToTabs variants. I would have to double check to see what entab means. ljustify - leftJustify /justifyLeft left/rightJustify is better, IMHO. lowercase - lowercaseChars lowercase is fine as is. newline - newline Mild preference for newLine, but either would be fine. stripl - stripLeft stripr - striptRight Yes, even though differs from left/rightJustify usage. tolower - toLower/toLowercase/toLowerCase tolowerInPlace - toLowerInPlace/toLowercaseInPlace/toLowerCaseInPlace toLower and toLowerInPlace toupper - toUpper/toUppercase/toUpperCase toupperInPlace - toUpperInPlace/toUppercaseInPlace/toUpperCaseInPlace Ditto: toUpper and toUpperInPlace whitespace - whitespaceCharsr whitespace is fine as is. -- /Jacob Carlborg
Re: renamepalooza time
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.804.1295659471.4748.digitalmar...@puremagic.com... Personally, camelcase vs underscores isn't even something that I normally think about. I just always use camelcase. On _rare_ occasion, I might use underscores because it seems to fit a particular situation, but that's _really_ rare. The only time that I normally stick underscores in variable names is to indicate private member variables. But I find using underscores in names to generally be ugly and noisy. I expect that a lot of that just comes down to what you're used to though. I'm the same way. Plus, I find it really awkward to constantly type a bunch of underscores. It feels less like typing and more like finger acobatics.
Re: renamepalooza time
Jonathan M Davis wrote: On Friday, January 21, 2011 13:30:11 Ali Çehreli wrote: Andrei Alexandrescu wrote: iswhite I like separating is with an underscore, like most coding styles do: is_whitespace Warm and fuzzy... :) Most? I've never dealt with a coding style that had underscores. Sorry for being unclear. My comment was only in the context of is_. I like separating is with an underscore. Probably because is is not part of the name. It operates at a different linguistic level. It's generally camelcase, though I get the impression that using underscores in C code is more common (I've mostly used C++ and Java). Same here: always camelcase, except in our C libraries. Now I like underscore more than before. :) Regardless however, Phobos' coding style uses camelcase, not underscores. And this whole thread was started to try and find better names for functions which need new names, because they don't currently follow Phobos' naming conventions. I am aware of that. Then half seriously, let's change the standard to use underscore after is. Also when parts of a camelcased name are too loosely related. For example, when NodeReader is an interface and when we already have a LovelyDb, we may have a class named LovelyDb_NodeReader. Ali
Re: renamepalooza time
I'm the same way. Plus, I find it really awkward to constantly type a bunch of underscores. It feels less like typing and more like finger acobatics. It is worse for camelCase, at least you can bind _ to another key. Only one thing i like about camelCase is that, it takes less space.
Re: renamepalooza time
so s...@so.do wrote in message news:op.vpqi7ngy7dtt59@so-pc... I'm the same way. Plus, I find it really awkward to constantly type a bunch of underscores. It feels less like typing and more like finger acobatics. It is worse for camelCase, Don't see how. iT vs i_t: iT: [i] [hold shift] [t] [release shift] i_t: [i] [hold shift] [reach over to -] [release shift] [t] at least you can bind _ to another key. I already use all my other keys.
Re: renamepalooza time
That's why they invented the concept of rebinding the keys. And why Vim is a modal editor. Etc etc etc..
Re: renamepalooza time
On 01/23/2011 12:03 AM, Ali Çehreli wrote: Jonathan M Davis wrote: On Friday, January 21, 2011 13:30:11 Ali Çehreli wrote: Andrei Alexandrescu wrote: iswhite I like separating is with an underscore, like most coding styles do: is_whitespace Warm and fuzzy... :) Most? I've never dealt with a coding style that had underscores. Sorry for being unclear. My comment was only in the context of is_. I like separating is with an underscore. Probably because is is not part of the name. It operates at a different linguistic level. It's generally camelcase, though I get the impression that using underscores in C code is more common (I've mostly used C++ and Java). Same here: always camelcase, except in our C libraries. Now I like underscore more than before. :) Regardless however, Phobos' coding style uses camelcase, not underscores. And this whole thread was started to try and find better names for functions which need new names, because they don't currently follow Phobos' naming conventions. I am aware of that. Then half seriously, let's change the standard to use underscore after is. Also when parts of a camelcased name are too loosely related. For example, when NodeReader is an interface and when we already have a LovelyDb, we may have a class named LovelyDb_NodeReader. Ali Nice sensible way of mixing both conventions :-) Sounds similar to using whitespace for visual grouping like in a*b + c*d or [ [1,2,3] , [4,5,6] ] But may be a bit too complicated for a public, free-willing, style, don't you think? Rather for an enforced project or corporate one, I'd say... Denis _ vita es estrany spir.wikidot.com
Re: renamepalooza time
On 01/23/2011 02:39 AM, Nick Sabalausky wrote: sos...@so.do wrote in message news:op.vpqi7ngy7dtt59@so-pc... I'm the same way. Plus, I find it really awkward to constantly type a bunch of underscores. It feels less like typing and more like finger acobatics. It is worse for camelCase, Don't see how. iT vs i_t: iT: [i] [hold shift] [t] [release shift] i_t: [i] [hold shift] [reach over to -] [release shift] [t] Depends on your keyboard, Nick: '_' does not require shift, on mine (don't ask why). But '[' ']' require AltGr :-( Think they are directly accessible on US keyboards, aren't they? This would explain they massive use in PLs. denis _ vita es estrany spir.wikidot.com
renamepalooza time
The following symbols in std.string don't satisfy the Phobos naming conventions and need to be renamed: LS PS capwords countchars entab expandtabs hexdigits icmp iswhite ljustify lowercase maketrans newline octdigits removechars rjustify sformat splitlines stripl stripr tolower tolowerInPlace toupper toupperInPlace tr whitespace zfill Opinions on what to rename? Thanks, Andrei
Re: renamepalooza time
Andrei Alexandrescu wrote: The following symbols in std.string don't satisfy the Phobos naming conventions and need to be renamed: LS PS capwords countchars entab expandtabs hexdigits icmp iswhite ljustify lowercase maketrans newline octdigits removechars rjustify sformat splitlines stripl stripr tolower tolowerInPlace toupper toupperInPlace tr whitespace zfill Opinions on what to rename? Thanks, Andrei Are there any conventions beyond what case to use? I see this common pattern: verb-noun (expand-tabs) but for what I think is called adverbs in English it is a bit mixed (ljustify vs stripl). These ones should be simply lower camel case: capwords countchars entab expandtabs hexdigits octdigits removechars tolower tolowerInPlace toupper toupperInPlace lowercase maketrans splitlines newline and whitespace: not sure how it is called in English, but these look like they have become single words and are fine. LS and PS: since these are constants, upper case is ok, although LS is inconsistent with std.path.linesep. iswhite - isWhitespace tr: would say translate, but it's already there. Doesn't it overlap too much? Then these remain, I'm less sure about them: icmp ljustify rjustify sformat stripl stripr zfill Possibly: icmp: ok, it's a single abbreviation and insensitiveCompare is too much ljustify - leftJustify rjustify - rightJustify sformat - stringFormat (?) stripl - leftStrip stripr - rightStrip zfill - zeroFill (or better, ditch it and overload justify to take the filling char)
Re: renamepalooza time
On Thursday 20 January 2011 23:57:39 Andrei Alexandrescu wrote: The following symbols in std.string don't satisfy the Phobos naming conventions and need to be renamed: LS PS capwords countchars entab expandtabs hexdigits icmp iswhite ljustify lowercase maketrans newline octdigits removechars rjustify sformat splitlines stripl stripr tolower tolowerInPlace toupper toupperInPlace tr whitespace zfill Opinions on what to rename? LS = lineSep PS = paragraphSep capwords = capitalizeWords? capWords? countchars = countChars Well, entab, I'd argue _does_ follow the naming convention, because entab would be a verb, albeit a made up one. Certainly, en is a prefix, not another word, so I think that entab is fine. If that doesn't fly, then go with enTab, I guess, but I'd argue that entab is a single word and fine as it is. expandtabs = expandTabs hexdigits = hexDigits icmp, I'd actually be tempted to just leave as-is, since it's simple and clear and goes well with cmp. But if that's not acceptable, I guess that I'd suggest cmpIgnoreCase. It is a tad verbose though. Or I suppose that you could just do iCmp. iswhite = isWS, isWhitespace, or isWhite (I'd probably pick isWS) ljustify = leftJustify lowercase = lettersLC maketrans = makeTransTable I'd leave newline as is. newline is pretty much used as a single word like that in programming when talking about \n, so I'd consider it one word, and so it's fine as-is. octdigits = octDigits removechars = removeChars rjustify = rightJustify sformat = formatInPlace? I'm not sure that I quite get what this function does though. splitlines = splitLines stripl = stripLeft (though honestly, I kind of like stripl and stripr, and it's just dumb to capitalize the last letter) stripr = stripRight tolower = toLower tolowerInPlace = toLowerInPlace toupper = toUpper toupperInPlace = toUpperInPlace tr? The name means nothing to me. I haven't a clue where the name comes from, so I can't really give a better version of the same name. As it is, tr seems fine to me, particularly since tR just seems stupid. It should probably get a more descriptive name though. replaceChars? Similar to newline, I'd consider whitespace to be one word and just fine as is. After all, you don't type new line or white space when talking about newlines or whitespace. newline and whitespace are both whole words with special meaning in the world of programming. zfill is just a weird name. It's slighty better than tr in that it does fill in the string, but truth be told, without reading the source code, I don't know what it really does. I would _expect_ that the justify functions would move whatever space was around the string to the left, right, or both depending on which justify function you use, but I don't know. And how would that relate to filling in the string with 0's? Does it use 0 instead of spaces? The simplest would be to just rename it zFill, but unless zfill is a semi-standard/common name from other languages or libraries, a more descriptive name might be preferable. I have no idea what that would be though. - Jonathan M Davis
Re: renamepalooza time
On Friday 21 January 2011 00:44:26 Jonathan M Davis wrote: On Thursday 20 January 2011 23:57:39 Andrei Alexandrescu wrote: The following symbols in std.string don't satisfy the Phobos naming conventions and need to be renamed: LS PS capwords countchars entab expandtabs hexdigits icmp iswhite ljustify lowercase maketrans newline octdigits removechars rjustify sformat splitlines stripl stripr tolower tolowerInPlace toupper toupperInPlace tr whitespace zfill Opinions on what to rename? LS = lineSep PS = paragraphSep capwords = capitalizeWords? capWords? countchars = countChars Well, entab, I'd argue _does_ follow the naming convention, because entab would be a verb, albeit a made up one. Certainly, en is a prefix, not another word, so I think that entab is fine. If that doesn't fly, then go with enTab, I guess, but I'd argue that entab is a single word and fine as it is. expandtabs = expandTabs hexdigits = hexDigits icmp, I'd actually be tempted to just leave as-is, since it's simple and clear and goes well with cmp. But if that's not acceptable, I guess that I'd suggest cmpIgnoreCase. It is a tad verbose though. Or I suppose that you could just do iCmp. iswhite = isWS, isWhitespace, or isWhite (I'd probably pick isWS) ljustify = leftJustify lowercase = lettersLC maketrans = makeTransTable I'd leave newline as is. newline is pretty much used as a single word like that in programming when talking about \n, so I'd consider it one word, and so it's fine as-is. octdigits = octDigits removechars = removeChars rjustify = rightJustify sformat = formatInPlace? I'm not sure that I quite get what this function does though. splitlines = splitLines stripl = stripLeft (though honestly, I kind of like stripl and stripr, and it's just dumb to capitalize the last letter) stripr = stripRight tolower = toLower tolowerInPlace = toLowerInPlace toupper = toUpper toupperInPlace = toUpperInPlace tr? The name means nothing to me. I haven't a clue where the name comes from, so I can't really give a better version of the same name. As it is, tr seems fine to me, particularly since tR just seems stupid. It should probably get a more descriptive name though. replaceChars? Similar to newline, I'd consider whitespace to be one word and just fine as is. After all, you don't type new line or white space when talking about newlines or whitespace. newline and whitespace are both whole words with special meaning in the world of programming. zfill is just a weird name. It's slighty better than tr in that it does fill in the string, but truth be told, without reading the source code, I don't know what it really does. I would _expect_ that the justify functions would move whatever space was around the string to the left, right, or both depending on which justify function you use, but I don't know. And how would that relate to filling in the string with 0's? Does it use 0 instead of spaces? The simplest would be to just rename it zFill, but unless zfill is a semi-standard/common name from other languages or libraries, a more descriptive name might be preferable. I have no idea what that would be though. - Jonathan M Davis Also, I'd suggest that we not be OCD about our naming conventions. We should strive to stick to camel-casing function names with the first letter being lowercase, but if there's a function that just looks better not quite following the conventions, then we should go with that - particularly if camel-casing everything leads to really long names everywhere. For instance, I have no problem with stripl. I think that it would be stupid to just make the last letter uppercase, and stripLeft is more verbose. The same goes for icmp. icmp fits really well with cmp, and pretty much anything which tries to camel-case it becomes excessively verbose. So, I think that we should generally follow our naming conventions, but I don't think that we should absolutely require that they be followed _exactly_ all the time - just like sometimes it's better to format code somewhat differently from what a coding standard requires, because in a particular case, the result of following the standard would be much harder to read, even if following the standard _normally_ leads to more readable code. - Jonathan M Davis
Re: renamepalooza time
On Fri, 21 Jan 2011 01:57:39 -0600, Andrei Alexandrescu wrote: The following symbols in std.string don't satisfy the Phobos naming conventions and need to be renamed: LS PS capwords countchars entab expandtabs hexdigits icmp iswhite ljustify lowercase maketrans newline octdigits removechars rjustify sformat splitlines stripl stripr tolower tolowerInPlace toupper toupperInPlace tr whitespace zfill Opinions on what to rename? I think the following are fine, because you would most likely write them as single words in ordinary text: entab, lowercase, newline, whitespace These should simply be camelCased: countChars, expandTabs, hexDigits, removeChars, splitLines, toLower, toLowerInPlace, toUpper, toUpperInPlace These should be expanded a bit and camelCased: LS:lineSep, lineSeparator PS:paragraphSep, paragraphSeparator capwords: capitalizeWords iswhite: isWhitespace ljustify: leftJustify maketrans: makeTranslation octdigits: octalDigits rjustify: rightJustify sformat: formatString stripl:stripLeft stripr:stripRight zfill: zeroFill I don't know about icmp. I guess I would prefer both cmp and icmp to be renamed to compare and compareCaseInsensitive. I really have no idea what to call tr. -Lars
Re: renamepalooza time
On Fri, 21 Jan 2011 09:05:24 +, Lars T. Kyllingstad wrote: sformat: formatString Forget that; I confused sformat() and format(). But maybe sformat should be renamed formatInPlace? I dunno. -Lars
Re: renamepalooza time
On 2011-01-21 08:57, Andrei Alexandrescu wrote: The following symbols in std.string don't satisfy the Phobos naming conventions and need to be renamed: LS PS capwords countchars entab expandtabs hexdigits icmp iswhite ljustify lowercase maketrans newline octdigits removechars rjustify sformat splitlines stripl stripr tolower tolowerInPlace toupper toupperInPlace tr whitespace zfill Opinions on what to rename? Thanks, Andrei LS - lineSeparator/LineSeparator PS - paragraphSeparator/ParagraphSeparator capwords - capitalizeWords/capitalizeAll // should this function really mess with whitespaces ? countchars - countChars/count entab - entab/spacesToTabs expandtabs - expandTabs/tabsToSpaces hexdigits - hexDigits icmp - insensitiveCompare iswhite - isWhitespace ljustify - leftJustify /justifyLeft lowercase - lowercaseChars maketrans - makeTranslationTable // is this really needed, can't translate to this newline - newline octdigits - octalDigits removechars - removeChars/remove rjustify - rightJustify/justifyRight sformat - formatInPlace splitlines - splitLines stripl - stripLeft stripr - striptRight tolower - toLower/toLowercase/toLowerCase tolowerInPlace - toLowerInPlace/toLowercaseInPlace/toLowerCaseInPlace toupper - toUpper/toUppercase/toUpperCase toupperInPlace - toUpperInPlace/toUppercaseInPlace/toUpperCaseInPlace tr - replaceWithmModifiers whitespace - whitespaceCharsr zfill - zeroFill -- /Jacob Carlborg
Re: renamepalooza time
Andrei Alexandrescu Wrote: The following symbols in std.string don't satisfy the Phobos naming conventions and need to be renamed: LS PS capwords countchars entab expandtabs hexdigits icmp iswhite ljustify lowercase maketrans newline octdigits removechars rjustify sformat splitlines stripl stripr tolower tolowerInPlace toupper toupperInPlace tr whitespace zfill Opinions on what to rename? Thanks, Andrei A few notes: A) As discussed already in the thread about Unicode, some string algorithms depend on locale/language. From what I see in the docs this isn't handled properly at the moment. Is it possible to remove/deprecate the functions or at least add a warning in the docs? I prefer them to be marked as deprecated rather than renamed since they hopefully will be replaced anyway in the future. B) I prefer trim over strip as it is more descriptive IMO: stripl = leftTrim stripr = rightTrim strip sounds to me like something related to clothing.
Re: renamepalooza time
On 01/21/2011 09:43 AM, Lutger Blijdestijn wrote: newline and whitespace: not sure how it is called in English, but these look like they have become single words and are fine. I would not make such exceptions because there is no rational criterion to determine which multiple-word terms have become kinds of single-word terms, in english, AFAIK (eg: filename, dirname, drivename, fullname, shortname?). Anyway, D is not an english dialect, it just reuses the english lexicon. Programmers would be left in constant doubt. Thus, the only practical scheme is a systematic rule: more-than-one-word == camel-case. It's more annoying to type, agreed, for common 2-words-only terms; but one can then always guess what the correct form is --without any doubt. Also: very newcomer friendly. Denis _ vita es estrany spir.wikidot.com
Re: renamepalooza time
On 01/21/2011 09:43 AM, Lutger Blijdestijn wrote: LS and PS: since these are constants, upper case is ok, although LS is inconsistent with std.path.linesep. Consistency across stdlib modules and with D builtin names (esp types) would be even more helpful than proper casing, imo. [Also: Is there any chance to have a builtin name reform for Dn? This could be progressive: introduce builtin aliases -- deprecate non-conformant ones -- let conformant ones only.] Denis _ vita es estrany spir.wikidot.com
Re: renamepalooza time
On 01/21/2011 09:44 AM, Jonathan M Davis wrote: Well, entab, I'd argue_does_ follow the naming convention, because entab would be a verb, albeit a made up one. Certainly, en is a prefix, not another word, so I think that entab is fine. If that doesn't fly, then go with enTab, I guess, but I'd argue that entab is a single word and fine as it is. I fully agree with you on the linguistic side: entab is a single-word term, just like eg input (no-one would suggest inPut ;-). But practically, the decomposition enTab helps understanding this identifier by nicely highlighting tab, don't you think? This is even more relevant for foreigners, who have here to guess: (1) that entab is not a 'normal' english single-word term they would just not know (2) as you say, that en- is a verb-forming prefix in english one can more or less freely use. Non-trivial. Denis _ vita es estrany spir.wikidot.com
Re: renamepalooza time
On 01/21/2011 10:14 AM, Jacob Carlborg wrote: ljustify - leftJustify /justifyLeft rjustify - rightJustify/justifyRight stripl - stripLeft stripr - striptRight Consistency. Eg: all qualifiers come first (like in english). Denis _ vita es estrany spir.wikidot.com
Re: renamepalooza time
On 01/21/2011 10:05 AM, Lars T. Kyllingstad wrote: These should be expanded a bit and camelCased: LS:lineSep, lineSeparator PS:paragraphSep, paragraphSeparator Isn't there a rule that constants all fully uppercase? Denis _ vita es estrany spir.wikidot.com
Re: renamepalooza time
ljustify - leftJustify rjustify - rightJustify stripl - leftStrip stripr - rightStrip I suggest it should be rather justifyLeft/Right and stripLeft/Right. It's easier to read and it works better with code completion.
Re: renamepalooza time
On Friday, January 21, 2011 06:04:53 spir wrote: On 01/21/2011 09:44 AM, Jonathan M Davis wrote: Well, entab, I'd argue_does_ follow the naming convention, because entab would be a verb, albeit a made up one. Certainly, en is a prefix, not another word, so I think that entab is fine. If that doesn't fly, then go with enTab, I guess, but I'd argue that entab is a single word and fine as it is. I fully agree with you on the linguistic side: entab is a single-word term, just like eg input (no-one would suggest inPut ;-). But practically, the decomposition enTab helps understanding this identifier by nicely highlighting tab, don't you think? This is even more relevant for foreigners, who have here to guess: (1) that entab is not a 'normal' english single-word term they would just not know (2) as you say, that en- is a verb-forming prefix in english one can more or less freely use. Non-trivial. I'm afraid that I don't agree at all. enTab is hideous and arguably confusing precisely because en is _not_ a word. I'd start trying to figure out what en was short for if I saw an enTab function. entab is _far_ clearer. Would you make a function named enClose? I should hope not. Granted, enclose is actually a word that you'll find in a dictionary, but en is a normal prefix in English, and trying to treat it as a word or abbrevation in function names would just be confusing. - Jonathan M Davis
Re: renamepalooza time
On Friday, January 21, 2011 06:20:30 spir wrote: On 01/21/2011 10:05 AM, Lars T. Kyllingstad wrote: These should be expanded a bit and camelCased: LS:lineSep, lineSeparator PS:paragraphSep, paragraphSeparator Isn't there a rule that constants all fully uppercase? That would be typical in C++ or Java, but that's not the case in D. Phobos certainly doesn't work that way in general, and Andrei doesn't want it to. The reasoning is that constants are so common in D (likely due to CTFE) that you'd have variables all over the place which were in all caps, and it would get really annoying. So, no. There is no rule in D that constants should be fully uppercase. - Jonathan M Davis
Re: renamepalooza time
On Friday, January 21, 2011 06:16:16 spir wrote: On 01/21/2011 10:14 AM, Jacob Carlborg wrote: ljustify - leftJustify /justifyLeft rjustify - rightJustify/justifyRight stripl - stripLeft stripr - striptRight Consistency. Eg: all qualifiers come first (like in english). Actually, it's a bit funny in this case. You're stripping the left of the string or the right of the string, so stripLeft and stripRight make a lot more sense than leftStrip and rightStrip (actually, those would be pretty horrible IMO). However, when talking about justifying text, you typically talk about it being left-justified or right-justified (or centered). So, it's more natural to have leftJustify and rightJustify. Now, it might technically be more correct to talk about justifying it to the right or left, but no one really talks that way. I believe that left justify and right justify are typically used as if they were composite verbs rather than talking about justifying text to the right or left. So, it's going to make more sense to most people to have stripLeft, stripRight, leftJustify, and rightJustify rather than trying to put right and left on the same side for both strip and justify. - Jonathan M Davis
Re: renamepalooza time
Jonathan M Davis wrote: On Friday, January 21, 2011 06:20:30 spir wrote: On 01/21/2011 10:05 AM, Lars T. Kyllingstad wrote: These should be expanded a bit and camelCased: LS:lineSep, lineSeparator PS:paragraphSep, paragraphSeparator Isn't there a rule that constants all fully uppercase? That would be typical in C++ That is typical only for macros in C++. I know that some shops use all capitals for constants, but not the standard library nor any of the places that I worked at. :) Ali
Re: renamepalooza time
Andrei Alexandrescu wrote: iswhite I like separating is with an underscore, like most coding styles do: is_whitespace Warm and fuzzy... :) Ali
Re: renamepalooza time
Jonathan M Davis napisał: These should be expanded a bit and camelCased: LS:lineSep, lineSeparator PS:paragraphSep, paragraphSeparator Isn't there a rule that constants all fully uppercase? That would be typical in C++ or Java, but that's not the case in D. Phobos certainly doesn't work that way in general, and Andrei doesn't want it to. The reasoning is that constants are so common in D (likely due to CTFE) that you'd have variables all over the place which were in all caps, and it would get really annoying. Right on. So, no. There is no rule in D that constants should be fully uppercase. So if not uppercase, what is the convention for constants then? And, to hair-split more, what is a constant to begin with? Would e.g. a big immutable configuration tree structure fall into that bucket? Or a logger object? -- Tomek
Re: renamepalooza time
On Friday, January 21, 2011 13:46:11 Tomek Sowiński wrote: Jonathan M Davis napisał: These should be expanded a bit and camelCased: LS:lineSep, lineSeparator PS:paragraphSep, paragraphSeparator Isn't there a rule that constants all fully uppercase? That would be typical in C++ or Java, but that's not the case in D. Phobos certainly doesn't work that way in general, and Andrei doesn't want it to. The reasoning is that constants are so common in D (likely due to CTFE) that you'd have variables all over the place which were in all caps, and it would get really annoying. Right on. So, no. There is no rule in D that constants should be fully uppercase. So if not uppercase, what is the convention for constants then? And, to hair-split more, what is a constant to begin with? Would e.g. a big immutable configuration tree structure fall into that bucket? Or a logger object? As far as Phobos goes, constants are named the same way that any other variable is. I don't think that there are any special naming conventions based on variable type or constness or whatnot. It's all based on the type of symbol. Typically, everything is camelcase, user-defined types start with a capital letter, and everything else starts with a lowercase letter. The most typical constants are enums, but there are cases where you can't do that, because CTFE isn't advanced enough yet (like with you configuration tree structure), in which case immutable is used along with static constructors. Ideally though, they'd pretty much always be generated with CTFE and be enums. Generally-speaking, when referring to constants, people are referring to variables with a global lifetime which are set to an initial value and never (and cannot ever) change once set. - Jonathan M Davis
Re: renamepalooza time
On Friday, January 21, 2011 13:30:11 Ali Çehreli wrote: Andrei Alexandrescu wrote: iswhite I like separating is with an underscore, like most coding styles do: is_whitespace Warm and fuzzy... :) Most? I've never dealt with a coding style that had underscores. It's generally camelcase, though I get the impression that using underscores in C code is more common (I've mostly used C++ and Java). Regardless however, Phobos' coding style uses camelcase, not underscores. And this whole thread was started to try and find better names for functions which need new names, because they don't currently follow Phobos' naming conventions. - Jonathan M Davis
Re: renamepalooza time
Jonathan M Davis: Most? I've never dealt with a coding style that had underscores. It's generally camelcase, though I get the impression that using underscores in C code is more common (I've mostly used C++ and Java). Regardless however, Phobos' coding style uses camelcase, not underscores. You are right. But I'd like to know why Phobos uses camelcase instead of underscores (as used in C and Python). I think variable names in camelcase are less noisy. Bye, bearophile
Re: renamepalooza time
On 01/22/2011 12:17 AM, bearophile wrote: You are right. But I'd like to know why Phobos uses camelcase instead of underscores (as used in C and Python). I think variable names in camelcase are less noisy. I have used underscores for a long time, then had to switch to camelcase for conformance with an enforced coding style. Annoyed for a while. Then, I realised that camelcase may be better because it is visually clearer in complicated expressions; I mean '_' is too shy, it doesn't obviously enough tie together parts of a single identifier. Even '-' (heavily used in languages that allow it) is too shy. I also don't like '_' at start/end of ids for similar reasons. xyz.foo_._bar (param); (But it's only me...) Denis _ vita es estrany spir.wikidot.com
Re: renamepalooza time
I think variable names in camelcase are less noisy. Sorry, I meant: I think variable names in camelcase are more noisy. Bye, bearophile
Re: renamepalooza time
On 01/21/2011 10:46 PM, Tomek Sowiński wrote:
So if not uppercase, what is the convention for constants then? And, to
hair-split more, what is a constant to begin with? Would e.g. a big immutable
configuration tree structure fall into that bucket? Or a logger object?
Very personal def: I give constant variable about the same meaning as
in math: something predefined, or conversely undefined, at design time
(which implies in a compiled language also at compile-time).
f : x -- k.x
k is a constant, x a variable. Same below:
factor3 = 3;
int triple (int x) {return factor3 * x;}
Thus, I consider enum and static (in some of its numerous senses) as
constant qualifiers.
Denis
_
vita es estrany
spir.wikidot.com
Re: renamepalooza time
On 1/21/11 4:49 PM, Jonathan M Davis wrote: On Friday, January 21, 2011 13:30:11 Ali Çehreli wrote: Andrei Alexandrescu wrote: iswhite I like separating is with an underscore, like most coding styles do: is_whitespace Warm and fuzzy... :) Most? I've never dealt with a coding style that had underscores. It's generally camelcase, though I get the impression that using underscores in C code is more common (I've mostly used C++ and Java). Regardless however, Phobos' coding style uses camelcase, not underscores. And this whole thread was started to try and find better names for functions which need new names, because they don't currently follow Phobos' naming conventions. Ever since I worked with STL, I fell in love with names_with_underscores. I can't explain it, but my feeling is that code using that convention is calm and levelheaded. Camel case forces me to think of one-word names because at the second word some beauty is already lost; never felt the same with the underscores. If I could go back in time I'd propose that convention throughout. Andrei
Re: renamepalooza time
Andrei Alexandrescu Wrote: Ever since I worked with STL, I fell in love with names_with_underscores. I can't explain it, but my feeling is that code using that convention is calm and levelheaded. Camel case forces me to think of one-word names because at the second word some beauty is already lost; never felt the same with the underscores. I like the look of the STL convention, but overall prefer that Camel case distinguishes between types and values. It completely eliminates the need for a _type suffix in STL-style typedefs, for one.
Re: renamepalooza time
On Friday, January 21, 2011 15:17:00 bearophile wrote: Jonathan M Davis: Most? I've never dealt with a coding style that had underscores. It's generally camelcase, though I get the impression that using underscores in C code is more common (I've mostly used C++ and Java). Regardless however, Phobos' coding style uses camelcase, not underscores. You are right. But I'd like to know why Phobos uses camelcase instead of underscores (as used in C and Python). I think variable names in camelcase are less noisy. Probably because Walter and/or other folks working on it early on preferred camelcase. I'm welling to bet that a fair number of the current Phobos devs are the same (though apparently, Andrei isn't, given one of his posts in this thread). I expect that Phobos uses camelcase simply because that's what enough of the Phobos developers (particularly early developers) were used to. Personally, camelcase vs underscores isn't even something that I normally think about. I just always use camelcase. On _rare_ occasion, I might use underscores because it seems to fit a particular situation, but that's _really_ rare. The only time that I normally stick underscores in variable names is to indicate private member variables. But I find using underscores in names to generally be ugly and noisy. I expect that a lot of that just comes down to what you're used to though. - Jonathan M Davis
Re: renamepalooza time
On 01/22/2011 01:16 AM, Andrei Alexandrescu wrote: Ever since I worked with STL, I fell in love with names_with_underscores. I can't explain it, but my feeling is that code using that convention is calm and levelheaded. Camel case forces me to think of one-word names because at the second word some beauty is already lost; never felt the same with the underscores. If I could go back in time I'd propose that convention throughout. Nice, surprising! I do not share your feeling (not at all), but I like very much the way you express it; and the weirdness to associate such a feeling with something_like_underscored_ids. Andrei Denis _ vita es estrany spir.wikidot.com
Re: renamepalooza time
Well, the underscored names might be easier to read since the words are spaced apart. They might be easier to type as well, if you set a hotkey for _. With camelcase you either have autocomplete to help you or you have to use Shift all the time (you need shift for _ as well unless you set a hotkey for it).
