Since "id" is a keyword in Objective-C what alternative name do you use for ID variable (e.g. PK field)?
I think it should be noted that the compiler can distinguish between id in the type specifier position and id in the variable name position. That is,
NSUInteger id;
id = 10;
will compile just fine (as, indeed, will id id; id = [NSNumber numberWithInt:10];). (You could also uppercase it: ID.) That said, those are all horrible ideas. Don't use them. Forget I even said that.
The style in Cocoa programming is to tend towards verbosity, so (as all the earlier answers have suggested) the best practice is probably to write it all out: identifier or dinglehopferID.
identifier, or something more specific like userID.
It often depends on context. Simply, identifier if I'm not feeling particularly creative.
I tend to use either 'identifier' — if there's really no better alternative — or something domain specific like 'programmeID' which sort of says 'this is the primary key, but only with respect to this domain'.
It's actually quite rare that you have to think in terms of primary keys within Cocoa. Core Data preserves object graphs without any nomination of primary keys, NSPredicates don't give inherently any additional weight to a field that happens to be unique per object and NSDictionarys tend to be built in an adhoc fashion.
I almost use 'guid' NSString *guid NSNumber *guid.
http://en.wikipedia.org/wiki/Globally_unique_identifier
Using id is a bad idea for me. I almost use 'uid' or 'cid' for Users and Clients respectively. I use the first letter of the model name to avoid the reserved word.
Related
I'm looking for some advice on SQL naming conventions. I know this topic has been discussed before but my question is a little more specific and I cannot find an answer elsewhere.
I have some integer variables - generally they would have a name like 'Timeout'. Is there an adopted standard prefixing/suffixing the value so that I know what it contains when I come back to it in 6 months time?
For instance is it 'TimeoutMilliseconds'.
I'm not talking about labelling every variable this way, just those with generic values.
Lookup ISO-11179 for the international database naming standard. for this you can grab this online for free download (though sorry I forget where). There is a lot in it, so here are some some basic summary form it:
Take your field description, remove joining words and write it backwards.
Always end with a class name. There are standard abbreviations like ID for identifier and such.
eg:
Date of Entry:
Entry_Date
Seconds_For_Delivery:
Delivery_Seconds
Name of Widget:
Widget_Name
Location of Widget:
Widget_Location
Size of Widget:
Widget_Size
Also a field should have the same name if it is a primary key or a referenced foreign key. This will pay off in readability for people that come after you, and also most DB tools will assume they are matching keys so you will also save time in using reporting tools and the like (less manual stuffing around putting links in by hand).
In the above examples, the class names are date, seconds, name, location, size. It surprises me that this ISO is not more well known.
The AdventureWorks Data Dictionary specifies that the [EmailPromotion] column in the [Contact] table is an int and that:
0 = Contact does not wish to receive e-mail promotions.
1 = Contact does wish to receive e-mail promotions.
and [Employee].[CurrentFlag] uses bit as follows:
0 = Inactive
1 = Active
My question has two parts:
Is there a good reason to use the int datatype in place bit (both uses will be documented)?
What naming conventions for boolean and boolean-like columns do you recommend? (e.g. IsActive, ActiveFlag, Active)
For the first part they are probably allowing for future status codes (although with that column name it is hard to imagine what that could be...).
You will find a lot of dissent on your second question, but I prefer IsActive as a name in this case. I find it reads well, and prevents double negatives in code that you would get if you used something like IsInactive.
Is there a good reason to use the int datatype in place bit (both uses will be documented)?
INT is consistently supported. While BIT is becoming more common, I'll wager the support is just a mask for an INT column with a CHECK constraint. There's a good asktom question about why Oracle doesn't have a specific BIT/BOOLEAN data type...
What naming conventions for boolean and boolean-like columns do you recommend? (e.g. IsActive, ActiveFlag, Active)
Same as programming, they should be prefixed with "is" and when read, should present a yes/no question to infer the column is a boolean indicator. So "isActive" would be my decision, but I would be probing to see if the situation didn't require a STATUS table & foreign key.
Whatever floats your boat. The only important thing is naming convention and consistency across the database.
Using int for a flag isn't justified, I would've used tinyint, I hardly ever use bit at all, because I'm always open for all kinds of possibilities out there.
I usually name those columns Active (if there are only two statuses) and StatusId (if there is more than one status).
Lets say i have a variable that contains the number of search engine names in a file, what would you name it?
number_of_seach_engine_names
search_engine_name_count
num_search_engines
engines
engine_names
other name?
The first name describes what the variable contains precisely, but isn't it too long?, any advice for choosing variable names? especially how to shorten a name that is too long or what kind of abbreviations to use?
How about numEngineNames?
Choosing variable names is more art than science. You want something that doesn't take an epoch to type, but long enough to be expressive. It's a subjective balance.
Ask yourself, if someone were looking at the variable name for the first time, is it reasonably likely that person will understand its purpose?
A name is too long when there exists a shorter name that equally conveys the purpose of the variable.
I think engineCount would be fine here. The number of engine names is presumably equal to the number of engines.
See JaredPar's post.
It depends on the scope of the variable. A local variable in a short function is usually not worth a 'perfect name', just call it engine_count or something like that. Usually the meaning will be easy to spot, if not a comment might be better than a two-line variable name.
Variables of wider scope – i.e. global variables (if they are really necessary!), member variables – deserve IMHO a name that is almost self documentary. Of course looking up the original declaration is not difficult and most IDE do it automatically, but the identifier of the variable should not be meaningless (i.e. number or count).
Of course, all this depends a lot on your personal coding style and the conventions at your work place.
Depends on the context, if its is a local variable, as eg
int num = text.scan(SEARCH_ENGINE_NAME).size();
the more explicit the right-hand of the expression the shorter the name I'd pick. The rational is that we are in a limited scope of maybe 4-5 lines and can thus assume that the reader will be able to make the connection between the short name and the right-hand-side expression. If however, it is the field of a class, I'd rather be as verbose as possible.
See similar question
The primary technical imperative is to reduce complexity. Variables should be named to reduce complexity. Sometimes this results in shorter names, sometimes longer names. It usually corresponds to how difficult it is for a maintainer to understand the complexity of the code.
On one end of the spectrums, you have for loop iterators and indexes. These can have names like i or j, because they are just that common and simple. Giving them longer names would only cause more confusion.
If a variable is used frequently but represents something more complex, then you have to give it a clear name so that the user doesn't have to relearn what it means every time they use it.
On the other end of the spectrum are variables that are used very rarely. You still want to reduce confusion here, but giving it a short name is less important, because the penalty for relearning the purpose of the variable is not paid very often.
When thinking about your code, try to look at it from the perspective of someone else. This will help not only with picking names, but with keeping your code readable as a whole.
Having really long variable names will muddle up your code's readability, so you want to avoid those. But on the other end of the spectrum, you want to avoid ultra-short names or acronyms like "n" or "ne." Short, cryptic names like these will cause someone trying to read your code to tear their hair out. Usually one to two letter variables are used for small tasks like being incremented in a for loop, for example.
So what you're left with is a balance between these two extremes. "Num" is a commonly used abbreviation, and any semi-experienced programmer will know what you mean immediately. So something like "numEngines" or "numEngineNames" would work well. In addition to this, you can also put a comment in your code next to the variable the very first time it's used. This will let the reader know exactly what you're doing and helps to avoid any possible confusion.
I'd name it "search_engine_count", because it holds a count of search engines.
Use Esc+_+Esc to write:
this_is_a_long_variable = 42
Esc+_+Esc and _ are not identical characters in Mathematica. That's why you are allowed to use the former but not the latter.
If it is a local variable in a function, I would probably call it n, or perhaps ne. Most functions only contain two or three variables, so a long name is unnecessary.
Can anyone confirm whether or not the SQL:1999 Array type Constructor provides any operations for searching the Array in a WHERE clause?.
As an Example If a table EMPLOYEES had a column
QUALIFICATION VARCHAR(20) ARRAY[10]
containing values such as ARRAY['BSC','MBA']
Does the standard support some way of querying EMPLOYEES to find all Employees with an MBA?
Well, you can always use an element reference (ISO/IEC 9075-2:1999, 6.13 ):
WHERE QUALIFICATION(1) = 'BSC'
OR QUALIFICATION(2) = 'BSC'
...
Of course, the problem is that you need to write a comparison for each possible position.
I am not aware of any operators that allows you to compare a scalar with an array, although I would suppose a DBMS that has native support for ARRAY types ould let you create a function that does the job.
I must say I never had the need for array types - I would typically build a one-to-many detail table, or in rare cases, add multiple columns (yeah - a repeating group. send the relational police to hunt me if you like :)
Would you care to explain why you need to know this, or what problem you are trying to solve with an ARRAY?
A table's boolean fields can be named using the positive vs the negative...
for example, calling a field:
"ACTIVE" , 1=on / 0=off
or
"INACTIVE" , 0=on / 1=off
Question:
Is there a proper way to make this type of table design decision, or is it arbitrary?
My specific example is a messages table with a bool field (private/public). This field will be set using a form checkbox when a user enters a new message. Is there a benefit in naming the field "public" vs "private"?
thanks.
I always prefer positive names, to avoid double negatives in code. "Is not inactive" is often cause for a double take when reading. "Is inactive" can always be written as "if (!Active)" whilst taking advantage of built-in language semantics.
My personal preference:
Use prefixes like "Is", "Has", etc. for Boolean fields to make their purpose clear.
Always name variables in the affirmative. For Active/Inactive, I would name it IsActive.
Don't make a bit field nullable unless you really have a specific purpose in doing so.
In your specific use case, the field should be named either IsPublic or IsPrivate--whichever name would result in a True answer when the user ticks the checkbox.
i would not disagree with some of the other answers but definitely avoid the incorrect answer which is not to put in double negatives always
Always use positive names.
If use negative names, you very quickly get into double negation. Not that double negation is rocket surgery, but it's a brain cycle and those are valuable :)
Always use positive.
It's simpler.
Take using the negation to the logical extreme: if InActive is better than Active, then why not InInActive, or InInInActive?
Because it would be less simple.
The proper way to handle these situations is to create a table to house the values associated with the column, and create a foreign key relationship between the two tables. IE:
WIDGETS table:
WIDGET_ID
WIDGET_STATUS (fk)
WIDGET_STATUS_CODES table:
WIDGET_STATUS_CODE (pk)
DESCRIPTION
If possible, WIDGET_STATUS_CODE would be a natural key (IE: ACT for "Active", INA for "Inactive"). This would make records more human readable, but isn't always possible so you'd use an artificial/surrogate key (like an auto-number/sequence/etc).
You want to do this because:
It's readable what status indicates (which was the original question)
Future proof in the need to define/use more statuses
Provides referencial integrity so someone couldn't set the value to 2, 3, 4, etc.
Space is cheap; there's nothing efficient about allowing bad data
Try to avoid boolean fields in databases alltogether.
One, the RM has a much better way to represent truth-valued information than via boolean fields : via the presence of a tuple in a table.
Two, boolean fields are very bad discriminators when querying. It's virtually complete madness to index them, so when querying, the presence of boolean fields gives no benefit at all.