In the latest code review I was asked, why did I change the method name from GetHDRFrame to GetHdrFrame, while HDR is an abbreviation. I'm pretty sure there was such recommendation in Code Complete: when using abbreviations in CamelCase names, treat them as regular words. But I cannot find the place where it is written. Could somebody give me an exact phrase in Code Complete, where it is stated?
There is a similar question with the useful links to MS rules, but I'm looking for Code Complete quote.
As far as I've been able to determine, there is no such advice in Code Complete. But it does say:
People have managed to have zealous, blistering debates over fine
points such as whether the first character in a name should be
capitalized (TotalPoints vs. totalPoints), but as long as you and
your team are consistent, it won't make much difference.
And that may help you avoid such nitpicking in future code reviews. ;-)
I saw an intern opportunity in a bank in dubai. They have a defined problem statement to be solved in 2 months. They told us just 2 lines -
"Basically the problem is about name matching logic.
There are two fields (variables) – both are employer names, and it’s a free text field. So we need to write a program to match these two variables."
Can anyone help me in understanding it? Is it just a simple pattern matching stuff?
Any help/comments would be appreciated.
I think this is what they are asking for:
They have two sources of related data, for example, one from an internal database, and the other from name card input.
Because the two fields are free text fields, there will be inconsistency. For example, Nitin Garg, or Garg, Nitin, or Mr. Nitin Garg, etc. Here is an extreme case of Gadaffi.
What you are supposed to do is to find a way to match all the names for a specific person together.
In short, match two pieces of data together by employer names, taking possible inconsistency into account.
Once upon a time there was a nice simple answer to the problem of matching up names despite mis-spellings and different transliterations - Soundex. But people have put a lot of work into this problem, so now you should probably use the results of that work, which is built into databases and add-ons - some free. See Fuzzy matching using T-SQL and http://anastasiosyal.com/archive/2009/01/11/18.aspx and http://msdn.microsoft.com/en-us/magazine/cc163731.aspx
The QA manager where I work just informed me there is a bug in my desktop app due to the sign-on prompt being "Operator Id" when it should be "Operator ID". Her argument being that "Id" refers to the ego portion of Freud's "psychic apparatus" and is not semantically correct.
Now being an anal engineer (AE) I of course had to go and lookup Id vs ID and from my cursory investigations (google) it seems ID is just as commonly used for Freud's ego as Id is.
So my reasoning would be that Id is a shortened version of "Identifier" and is more correct or at least more commonly used than ID which would typically indicate a two word abbreviation.
I could just change the UI but then I wouldn't be holding up my profession as an AE so I was wondering if there any best practices or references for this sort of thing that I could use to support my argument? Keeping in mind that this question relates to the user interface and not the source code where abbreviations and casing are a whole different branch of philosophy.
According to Merriam-Webster, the abbreviation is "ID". If it were a correct abbreviation, it would have to be "Id." with the period.
Personally, I use "Id". The compiler doesn't care but my eyes do. Compare:
GetIDByWhatever <-- looks terrible
GetIdByWhatever <-- oh so pretty!
Aesthetics is more important than grammar when it comes to code, always. (Update: 4 years later, I don't stand by this statement anymore)
The 'D' doesn't stand for anything, so I've always considered it an abbreviation, not an acronym - and therefore I too use 'Id', not 'ID'.
I don't know about your qa's reasoning - words can have more than one meaning - this is not unusual in English :)
But it looks like the common usage is actually 'ID' (right or wrong :P), which is probably the format your users would expect.
As an UAUA (ultra-anal usability analyst), please use ID instead of Id.
Visually, it's more recognizable in English. Grammatically, "Id" is a word (rhymes with "squid") and the Freudian definition has been given above. We're never verbally asked to show "id", but "ID." I.D. is fine but passe, as the periods imply multiple words.
So.
Just use ID, okay?
OK.
It's interesting that so many feel "Id" should be the way to go.
I feel "ID" is appropriate because it hints at how we pronounce it -- I.D. Also, when I read "Id" in a running sentence, I sometimes have to come back and read it again just to ensure it's not a typo for "is" or "it".
So, as a technical writer, this is an issue that comes up for me quite regularly when reviewing other people's work, whether it be programmers, BAs or other writers. Typically, id refers to ego as others have said before me and the accepted abbreviation for identification is ID, just because plenty of people don't know or understand the rule doesn't mean that they are correct (sorry to be blunt), mind you the rules for punctuation and spelling to a large degree are almost as changeable as fashion!
However, what no-one seems to have asked is, does your company have a standard? At the end of the day if your company has a style guide and they have covered this topic in that guide, you should follow the guide. If it is not covered, then may I suggest that you raise the issue with the person that maintains the guide and include any stakeholders in the conversation. Consistency is key here. If the company you work for doesn't have a style guide, then perhaps it is time to start one!
Hope this helps...
The QA manager's line of reasoning is silly. Lots of English words have multiple meanings. "Lead", "lead", "lead" (metal, be at the front of, or a connector).
I would just try to be consistent with the capitalization used elsewhere in the app.
User interface and code are very different beasts...
"ID" is the correct answer for a user interface.
In code, consistency is your friend. Whether you like it or not, go with what is already there elsewhere in the code. If it's not there, then read up and make a decision, or get with the team and work out a way to go that everyone can agree to. Consistency makes life so much easier.
I prefer Id because when used with other 2-letter text, it doesn't become a single all-caps word
Photovoltaics systems ... PVID (one word or 2?) PvId (much more clear).
ID = Idaho! Id = Freud! Let the OCD begin!
There is a little OcD in all of us!
Anyway, the google style guide says this:
"ID: Not Id or id, except in string literals or enums. In some contexts, best to spell out as identifier or identification."
I'm going with that.
Microsoft is more vague, from what I could find.
as a short version of Identifier, I would use Id. Also ID it's freaky when you have functions like
getUserIDByName()
Multiple capitals in domain terms are quite problematic with CamelCase, as they can produce ambiguities and therefore dishomogeneity in your interfaces and namings
How would you say it if you were reading out loud? I'd pronounce the two letters. ID is correct, analogous with similar abbreviations such as TV. (No dots, please, as the letters don't stand for anything.)
When I'm dealing with abbreviations like this, I like to format them in small block capitals, but that's just a personal taste. Capitals, anyway.
(But I probably would continue to use Id in the code itself.)
I think its depend on the way we spell. We don't spell "it", but "ai-di". Id-ID is spell by two sounds, so people make the D in cap to avoid thinking id is a "word". Its more like a character symbol. I like the "ID" more, just because it's nicer.
ID is correct. I have been in the Id camp for years, simply because I believed it was an argument between abbreviations and acronyms. Until one day I learned of a 3rd type (subtype really) called Initialisms which are specific to abbreviations or acronyms that are specifically read one letter at a time rather than pronounced as a single word. Initialisms are all caps.
for example i have an xpath and wish to add a comment near it to identify it.
/html/body/div/table/tr/td/a{this is a link}
XPATH 2.0 does allow comments.
From http://www.w3.org/TR/xpath20/#comments:
Comments may be used to provide informative annotation for an
expression. Comments are lexical constructs only, and do not affect
expression processing.
Comments are strings, delimited by the symbols (: and :). Comments may
be nested.
A comment may be used anywhere ignorable whitespace is allowed (see
A.2.4.1 Default Whitespace Handling).
The following is an example of a comment:
(: Houston, we have a problem :)
Bad news if we ever need to parse XML containing emoticons! :-)
As an aside - as I was looking for this info in the context of working with Tibco Designer for BusinessWorks v5.x, where comments can be added within the TIBCO Designer XPATH formula builder using:
{-- Houston, we've had a problem --}
Not a comment syntax, but you can give string literals as predicate, which evaluates as true (imho) and should not change the outcome of the expression. I don't know if this has big performance drawbacks.
/html/body/div/table["this is"]["a table"]/tr/td/a["this is a link"]
But like mjv said, I also would stick to the syntax of the host language.
2019 edit
As pointed out in #Sepster's reply and elsewhere, starting with XPath 2.0, comments became possible with their cute "smiley face"-looking syntax. I'm only about 10 years late in editing this reply to mention very useful fact ;-)
Original reply c. 2009 (assumed XPATH 1.0)
No, the XPATH syntax doesn't allow to embed comments within the path string.
This is typically not a significant limitation because paths are usually short and a comment can be placed nearby, in the particular syntax of the host language (XSLT, C#, whatever...)
The phrase was used as a warning that the code was pulling some serious stunts.
My google search for this is pulling up nada; but I remember someone doing a search of google source for the phrase quite a while back.
in lies dragons?
dragons sleep here...
Bah...
Here be Dragons.
originally sourced from old maps, not that any old maps actually used the term!
PS. Not recommended to use the original latin "hic sunt dracones" unless you want to be really nerdy and appear superior to future code maintainers :)
// Here be dragons
An example is in the source code of HipHop for PHP, at line 649 of /src/runtime/ext/ext_imagesprite.cpp as of July 13, 2012:
// Here be dragons. Thou art forewarned
If for some reason the programmer(s) doesn't quite understand what the code is doing, a comment saying "here be dragons" means that the code is "uncharted territory".
(Note my username :P)
Here be dragons
"Here be dragons" is displayed when you go to about:config in the address bar in Firefox.
Edit: Please note I'm in the UK so this may be locale specific.
Search over GitHub repositories shows 1,904 occurrences of "Here be dragons": https://grep.app/search?q=Here%20be%20dragons.
Examples:
500 lines long notes about the multi-precision division in Golang
clangd
kubernetes/kops
Twitter's Finangle
Chef