Are There Conventions on How to Name Resources

Are there conventions on how to name resources?

I don't know whether there are any official recommendations.

For ids in my layouts with widgets and containers, I use the convention:

<layout>_<widget/container>_<name>

I do the same strategy for any dimens, strings, numbers, and colors I use in those layouts. However, I do try generalizing. e.g if all buttons have a common textColor, I won't prefix the name with the layout. The resource name would be 'button_textColor'. If all textColors are using the same the resource it will be named 'textColor'. For Styles, this is usually the case as well.

For menu resources i use:

menu_<activity>_<name>

Animations are only different as you cannot use uppercase letters. Same goes for drawable xml resources, i believe.

Should I use Singular or Plural name convention for REST resources?

The premise of using /resources is that it is representing "all" resources. If you do a GET /resources, you will likely return the entire collection. By POSTing to /resources, you are adding to the collection.

However, the individual resources are available at /resource. If you do a GET /resource, you will likely error, as this request doesn't make any sense, whereas /resource/123 makes perfect sense.

Using /resource instead of /resources is similar to how you would do this if you were working with, say, a file system and a collection of files and /resource is the "directory" with the individual 123, 456 files in it.

Neither way is right or wrong, go with what you like best.

Azure - Naming convention for resources

An effective naming convention assembles resource names by using important resource information as parts of a resource's name.A public IP resource for a production SharePoint workload is named like this: pip-sharepoint-prod-westus-001

Straight From Microsoft Docs. Scroll down a little bit and you will find a whole bunch of great prefix to orginize your names.

Please notice that changing resource names can be difficult. Establish a comprehensive naming convention before you begin any large cloud deployment.

What is the best way to name REST resources when returning same resource but using different DTO?

A similar concept is called partial response which provide an option to let client to specify which fields to include in the response using the query parameters like:
:

/user?fields=name,surename

Basically you define a syntax for you own query language to represent a selection of fields. Here and Google Cloud API are some examples.

By taking this concept to a more coarse-grained level , you can use query parameter "view" to define different predefined combination of fields such as:

/users              //default view if no "view" query parameter is specified
/users?view=admin   //maybe this view will not show age field
/users?view=hr      //maybe this view only show the fields that are accessible to HR

Resource (.resx) file Key naming conventions?

Just use Pascal naming convention. Dont attribute the key to a module or the class. Generalize it so that it can be reused.

Eg: ReadWriteWarningMessage

The dot separated convention works fine for menu items. But what about strings that are generated dynamically or user messages.

Meaningful method name which create a resource when the one is not exist

I think the naming method/ function is not fully represent the actual process.

You must declare the function description in that function with comment.

And I think createAddrIfNotExist or createAccountIfNotExist are the good names.

What is the clearest way to name resources in Android?

The most important thing to remember, I think, is that it's perfectly fine to use the same ID across multiple layouts. For example, @id/title_bar is clean and generic and works, and so much simpler than @id/settings_title_bar, @id/home_screen_title_bar, @id/search_title_bar and so on.

I also like to name layouts destinated for activities as @layout/activity_home and @layout/activity_search etc. Drawables and icons should adopt the same standards as Android uses, i.e. @drawable/ic_btn_explode and @drawable/ic_dialog_exploded.

Includes can be tricky, but simpler ones which consist of only a few elements and serve a single, precise purpose tend to end up as @layout/loading or @layout/error_message.

I'm still working on naming strings sensibly, but again short, concise names make the whole process a lot easier.

Android: Naming Resources

Naming is pretty much personal preference. The name is perfect as long as the name indicates what the functionality of the defined thing is. Also you and any other developer using these definitions should know how what the names mean and which definition to choose. Quite easy if you are consistent with names throughout the project.

For example dark_blue is obviously a blue color while text_highlighted is the color of highlighted text. The name you should use depends on what you need: if you want to classify colors by their name take the first, if you like to abstract from the actual color take the second. For general layouts using text_highlighted will often make more sense since the actual color does not matter and the functionality (text highlight vs text regular etc.) is more important. In this example choosing between text_highlighted and text_regular is a lot more obvious than choosing between color_light_blue and color_dark_blue although they could refer to the same color. The name can help prevent errors.

Android uses prefixes for names in [android.R.drawable]
(http://developer.android.com/reference/android/R.drawable.html) for example:

• btn_ for button graphics
• ic_ for icon graphics
  
  • ic_menu_ for menu icons
  • ic_dialog_ for dialog icons
• stat_ for status icons

The schema is certainly not perfect but the advantage of using prefixes that start with the most generic classification is that you can use code completion to search for specific items step by step. So color_blue_dark could be better than dark_blue_color, at least if you consider the color classification more important than the dark / light classification. The same applies to first_time_prompt. If you have a lot of prompts it would make sense to name them prompt_first_time, promt_other_time, ... If they can be classified by an activity for example that could be used as super category: mainactivity_prompt_*, secondactivity_prompt_* so you know where they belong to.

REST API Resource Naming Conventions - User or Users (pluralisation)

There are obviously different opinions on this matter, the answer below contains my personal views.
The bottom line is that it's all quite subjective and depends on the way one looks at a certain (type of) resource.

Why would I use user when the resource refers to the entire users
database?

In my opinion, you should never use singular for an endpoint that contains multiple resources.

Some people, however, argue that we should stick to singulars for all resources, mostly for the sake of simplicity and uniformity.

Why would I use users when the resource only refers to the
authenticated user?

You will find quite some different opinions on this, but the consensus and most widely adopted is generally to stick with plurals, except for resources that can only contain a single item (for example, a user profile only containing only one avatar).

Also, since using a singular form for the users resource wouldn't make sense following the above logic, we don't want to mix singular and plural names.

// Update the authenticated user's device token
PUT /user/device

You can interpret 'updating the authenticated user's device token' as follows:

Add a device token to a user entity of the users resource collection.

---

Related Topics