Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 17 days ago.
Improve this question
Probably it's a simple question, but I have no clear which is the best naming convention for dto's classes and packages, in terms of package name, uppercase DTO or Dto for classes, etc... Example:
1. Package name:
xxx.dto.animal.Dog.class or xxx.animal.Dog.class
2. Uppercase dto Class Naming convention:
DogDTO or DogDto
3. Mixing both dto's conventions or neither.
The problem is, if I can declare the 'dto' word as a package or if the word 'dto' has to be included on the class name or both cases.
Try to avoid DTO suffix in class names. Including DTO in package names are fine.
You just need to decide how to use it in package names. Usually, I prefer my.feature1.dto, my.feature2.dto for example.
DTO is a very simple class so it should not be hard to recognize class to be DTO.
The most important thing is consistency!
Don't mix conventions.
If you work in a team on existing code, you have to be on the same page with them.
Otherwise, if you are refactoring a project or creating a new one, you can create a DTO folder and name your classes like the models, then use it as DTO.Dog.
Regarding the DogDTO VS DogDto question, I believe it depends on the language. In C# it would be DogDto based on Microsoft Capitalization Rules
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 days ago.
Improve this question
I have a question that may seem silly, my english is not very good, I often don't know how to name variables or methods.
For example, There is a method, its function is to open a modal for creating users, I will name it openCreateUserModal, Its corresponding English sentence is "open create user modal", I think this is not grammatical in English because there are two verbs. Would it be better to name it openCreatingUserModal？Or the method name does not need to follow English grammar?
I want to get a rule for naming complex methods
openCreateUserModal is perfectly fine. It clearly conveys what the function does. Following the rules of english grammar is not important in this context as long as the function name clearly indicates what the function does.
Since you haven't mentioned any particular language, below is a source c# naming conventions. The principles are the same for any programming language.
https://csharp-book.softuni.org/Content/Chapter-10-methods/method-naming/method-naming.html
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Which name is better, repository.UserRepository or repository.User?
I'm thinking about naming recently.
I have referenced several sources and they are talking.
Think about the context and name it.
Here is the link.
https://talks.golang.org/2014/names.slide#2
https://github.com/golang/go/wiki/CodeReviewComments
Additionally, Can you also recommend a project that can be referred to when creating an http server?
according to the golang official ducument
The importer of a package will use the name to refer to its contents, so exported names in the package can use that fact to avoid stutter. (Don't use the import . notation, which can simplify tests that must run outside the package they are testing, but should otherwise be avoided.) For instance, the buffered reader type in the bufio package is called Reader, not BufReader, because users see it as bufio.Reader, which is a clear, concise name. Moreover, because imported entities are always addressed with their package name, bufio.Reader does not conflict with io.Reader.
repository.User may be good then repository.UserRepository
the package in src/encoding/base64 is imported as "encoding/base64" not "encoding/base64Encoding"
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
There is only one convention I'm aware of in Golang for interface name - suffix single func interfaces with their method name plus "er". I've also noted another - Interface. As a package can only have one type with a name, I infer that it must be intended as the primary interface to the package - you could call this the "package interface".
My is there another reason?
Naming an interface type Interface isn't a convention–it's only used once in the standard library: sort.Interface.
Maybe the name Interface isn't the best or most intuitive one–Sortable would be more intuitive–but I guess the Go authors chose that name because together with the package name it is still better: sort.Interface vs sort.Sortable (the latter repeats sort).
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
Object-oriented languages can be categorized into two:
Class-based: like C++
Prototype-based: like JavaScript.
Ruby has class, so it is class-based. But its class is also an object. So is Ruby still a class-based language, or is it something in between? Is this a third category?
EDIT:
Ok, what I was wondering is, is other class-based language doing same thing like ruby, like create a class object of class Class?
In an object-oriented language, what else would a class be, than an object? If one of the most important things in an object-oriented language weren't an object, then the language wouldn't be very object-oriented, would it?
Classes are objects in many class-based OO languages. Smalltalk, Python, Ruby, Newspeak, you name it. There are some languages where they aren't, e.g. Java and C#, but even there you can get a reflective proxy object which represents a class.
Class is an instance of Class class. There is nothing in Ruby that goes against it being class based.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
There is a Style Guide for Protocol Buffers. But it does not clearly say how a .proto file should be named.
MyProtos.proto, my_protos.proto or my-protos.proto, which is the better name?
I don't believe there's an appropriate answer to how any file "should be named" other than aim for consistency and clarity.
Consistency would mean following the file-naming conventions your project already has for sources and headers. If your sources are named using camel-case, do the same for the proto files. The most common choice seems to me to be the my_protos.proto version.
Clarity to me means that the file name should give some clue as to the contents. I generally favour naming files after the class which they implement, and usually have a separate file (pair) per class. I would recommend the same for the proto files. I prefer several small proto files each defining a single Message or very closely related Messages over a single huge proto file defining all your Messages in the one place.
Since the question is almost 8 year old, for those who people looking at this in 2020 s, now there is a style guide published by google.
Excerpt for file naming
Files should be named lower_snake_case.proto
https://developers.google.com/protocol-buffers/docs/style