The convention is that you use your company's domain. That is quite simple but what if it is something like www.mycompany.co.uk.
Now this wouldn't be a problem if it were www.mycompany.com. That is fairly simple com.mycompany.Class
What are we meant to do with the first?
uk.co.mycompany.Class OR co.uk.mycompany.Class? Or something else altogether?
uk.co.mycompany.Class
It is a simple reverse of your URL. Note that in the first example the domain you actually own is mycompany.com, not just www.mycompany.com
If that is how your supposed to write your namespaces, I'd say that uk.co.mycompany.Class fits best with your first example.
It also seems to me that this is pretty subjective, and you should define a standard, and stick with it.
Related
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
I'm having a function called isIos() which returns true if the device is iOS (this is a cordova app).
iOS is the correct brand syntax but the coding style implmented used camelcase for the function name.
Should the function name be:
isIos() or isiOs() or isIOs() or something else?
What is the recommended way of dealing with this?
There's no general recommendation, your language might have guidelines that you might want to follow (doesn't seem the case with Node.js or javascript), or your company or application might have guidelines that you will have to follow, or there might be existing uses of the term in the application that you'll probably want to imitate, otherwise just use what seems easiest to read.
In this case, it might be isIOS, or isIos.
If you're using camel case though you should probalbly always put in upper case the first character of each word, isiOs() seems very confusing.
Your best option in these cases anyway is often to spare you the embarrassment and use a different name, if you can come up with one.
EDIT:
If you are not required to follow strict camel case you can also settle to is_iOS, which lets you keep the original case. This is probably the best alternative.
This is a question with no definite answer so apologies if I posted this wrongly however at my place of work alot of the code I see written by our developers have function names with the keyword 'should', must I add they base this on 'should' and 'should not'. From a point of semantics, whats your view on this? I've mentioned before that I don't believe this should be used because it has too many possibilities (where does it end) however they insist its a good practice.
Example use;
$this->it_should_render_template_partially($params);
$this->it_should_show_module_parameters($params);
$this->it_should_not_return_module_parameters($params);
I am curious on others thoughts. Just to add, this is production code and not unit tests.
While I like long, descriptive, names, I don't like redundancy. When I read the documentation of a function, I expect it to do what it is supposed to do. Yes, functions are written by humans that make a lot of mistakes, so they can have bugs, which means they do not behave as intended. But this is implied when one uses a function. We hope that out functions do what they should (and we try to make sure that is the case using tests). But specifying the should part in the name of a function is just redundant, which is, in my opinion, a bad practice, as it results in longer names, harder to read/write.
PostgreSQL has allowed me to name a column "campaign_$". I like the name because it's short and to the point, and other potential names like "campaign_receipts" seem longer and less clear.
BUT, I wonder if I'll eventually regret putting a $ symbol in a column name, either in PHP or in some other distant part of the architecture. Should I just stick to letters and underscores?
Thanks!
Yes, you should. "campaign_receipts" is a better name.
You probably won't regret, but I still wouldn't recommend it.
What happens when you expand into Europe?
Also, it will look strange and confusing to new developers.
In addition to the other excellent reasons I'll also mention that "$" in my mind is not clear at all. Does that mean campaign expenses? Campaign savings? Campaign values?
There's a VERY strong convention that tables and columns are named using only letters, numbers, and (possibly) underscores, so I would consider this poor style. Beyond the i18n concerns that other posters mention, there are probably a very large number of tools that expect table and column names following this convention.
I think it is bad practice to put special characters into a column name. Just spell out the word like campaign_money or campaign_funds and then the issue of internationalization or other possible issues become a thing of the past.
It should be fine, however it may cause you more problems down the line when you want to export the data to another system, things like that.
It's good to get into the habbit of naming columns/variables etc with no special characters, as usually they are more trouble than they are worth.
I wouldn't use it.
The "$" might not be valid in future databases you use (at some point you might migrate away from PostgreSQL to something else) and it also might pose problems at the application level if you do anything that maps column names to object properties if your programming language doesn't allow method names to have "$" in them.
Just my suggestion.
I'm trying to come up with some clear and concise names for a Permission class that lets you check if a permission is, was, or will be, allowed/denied. I'm at a loss for what to call the future tense.
class Permission:
def can_read()
def could_read()
def will_read()?
def will_be_readable()?
I'm most partial to will_read(), but it sounds funny. will_be_readable() is clear, but its kinda long, and will_be_read() sounds misleading.
Since you are looking for a permission class, the code will be formulated as a question:
if (the_user.can_read()) ...
if (the_user.can_read_past()) ...
if (the_user.can_read_future()) ...
Apart from that I would try to maintain equal prefixes for the semantically equal function, and I would leave off the suffix for the default/most likely case. I have no real problem sacrificing grammatical correctness for a logical naming structure, even though I like to gear code towards natural language. So something like that is what I would be going for.
The will_read() sounds more like an event that is triggered before the action.
EDIT: I am aware that "can_read_past" may be percieved as "can read old stuff". Maybe Scott Evernden's suggestion is better?
was, is, and will_be is clearest to me..
or maybe readable_before, readable_now, readable_later
Yeah, English really has a problem here, with no future tense of "can"! What about switching to (say) readable_now, readable_past, readable_future? If past and future have specific meanings in your case better naming could be worked out here, I'm sure.
Since it is related to if a permission is allowed/denied, maybe there is a more descriptive word than read?
can_authorize
authorized
scheduled_to_authorize
Which one is better:
1. www.example.com/category/123/books
2. www.example.com/category/123-books
I see stackoverflow uses option 1.
Are there any diferences for search engines on these url formats?
The difference is probably negligible. Many sites use either this or that format. Of course, only search engine insiders can tell the difference.
The first option is however easier for you to disassemble URL to parameters. I'd pick up that one (which I did for my blog).
The reason that stack overflow uses the first method is because it is passing the question ID via that section of the URL path. That is why Url SEO pk formatany-txt-will-do will still direct you to the same URL.
If your goal is to keyword stuff the URL (the main SEO advantage of friendly urls) then the first method is best as you consolidate the keyword into the file name.
For instance site.com/shop/cat/carriers.html is better than suited to rank for the term carriers. However, if your goal is to rank for the term "cat carriers" then site.com/shop/cat-carriers.html is better.
What it comes down to is your keyword parring. Many times when you are trying to rank a page, you have a base keyword and then modifiers. In the example above, cat is the keyword and carriers is the modifier. However, in a case like THAT you would be best to repeat the word cat, site.com/shop/cat/cat-carriers.html (as long as you don't look TO spammy that is).
You should note though, that a file named cat-carriers.html will not rank as well as carriers.html for the term carriers all other things being equal.
I would definitely use the first one
It is a somewhat common convention
You should make the slug optional. It is unclear it may be optional in the 2nd one.
URLs don't matter as much as people think they should. The first method is probably slightly better, but I think your site will rank the same with either one.
How to define urlrewritingnet rewrite rule for this, something like:
<add name="ProductDetailsRewrite" virtualUrl="^~/category/(.*)/(.*)" rewriteUrlParameter="ExcludeFromClientQueryString" destinationUrl="~/Category.aspx?CategoryID=$1" ignoreCase="true"/>
I am assuming "books" is the keyword you want to target with this example. Personally I prefer www.example.com/category/books-123 but out of the 2 given examples I would choose
www.example.com/category/123-books
Reason being the keyword is one jump less than that of example one. Granted it not a major ranking factor but if you are building the site up from scratch why not give it the best possible chance for success.
NOTE : for an existing site I will not go to the trouble of changing the url structure unless its absolutely required.