Prisma, is it able to use underscore name convetion?
I personally don`t like camel case because of readability..
But it seems to use underscore when composing things like constrained index or unique. And it seems to automatically change to camelCase when doing prisma migrate. Is it better to just do it in camelCase?
I've always done underscore naming, so it's inconvenient.
Related
This may be a self-answering question, but I'm hoping one of you could point me to any resource where it is declared, or can be inferred, whether to use upper or lower case letters when declaring an HTTP method name in HTTP or REST requests. The majority of examples I see put GET, PUT, POST, DELETE, PATCH etc in capital letters, whereas I go on the assumption that HTTP method field names are case insensitive - that is, for example, that "get" is equally as valid as "GET". Traditionally, I have always used capital letters, but I would just like to be sure.
The W3C explicitly declares that the method is case-sensitive and uses upper case, but in my travails, I've often encountered HTTP method field values using lower case, which I assume are incorrect, so from my point of view, it seems that practices and standards are somewhat out of touch on this matter.
Upper case is correct - right?
Method names are case-sensitive, and all registered methods are all upper-case.
(and the W3C really doesn't matter here; what's relevant are RFCs 7230 and 7231).
https://www.rfc-editor.org/rfc/rfc7231#section-4.1
yes as "Julian Reschk" said it should be upper-case by convention.
if you are using server like Django, Flask or Express (node) directly then your lower-case method names will be translated to upper-case automatically.
Frontent <---> Backend
but if there is a proxy in-between then it will a problem like nginx then you will get an error, also most services on cloud platforms like AWS, GCP, Azure use nginx behind the scenes. you will probably run in to this issue.
There was a discussion about that here in SO but I still have a question about that topic, though. So, a simple question: what is a naming convention for projects in Scala? Is it "my_new_project", "myNewProject", "my-new-project", "MyNewProject" or "mynewproject"? And the same question for packages.
Packages follow com.mycompany.myproject reversed-URL style. There is no naming convention for project names. Many people prefer all lower case with hyphenation like scala-foo. I prefer capitalised camel-case like ScalaFoo. It's a matter of taste. I have not seen scalaFoo as a project name convention, also underscore is not used (I think that's C or Python style?)
Like in the earlier days of Java, where almost every project begins with a J, there are a lot of projects beginning with scala. While I think this makes sense for porting existing libraries, I came to think that you should probably not call your project ScalaFoo or ScFoo but just Foo unless there is a specific reason to highlight the fact it's written in Scala.
You may take a look at the community libraries wiki to sense the taste for project names.
I don't know if there is a specific naming convention for projects in Scala, but usually the Java convention is used, so:
- thisIsAVariable (all but first word initial letter uppercase aka camelCase)
- ThisIsAClass (all initial letters uppercase aka PascalCase)
- com.example.www (reversed url for packages)
I've seen both camelCase and PascalCase for naming projects in Java, but I prefer PascalCase!
For projects, I have seen many people use my-new-project or MyNewProject frequently. I personally prefer MyNewProject. I have researched your question a lot and haven't found any set conventions for project names. I do believe on GitHub a lot of repositories use my-new-project and almost appears like it's their own convention for repository names.
For packages, the convention is to either use a company domain address or personal domain address with all lowercase letters in reverse order style: com.company.packagename.
Hope that helps!
Brady
When I create my function in postgres and call it something like getOrder it works just fine. However, when I then do a pg_dump, it dumps it as getorder, thus not preserving the case. That makes everything break if I have to do a restore.
I found I could get it to keep the case if I quote it, like:
CREATE FUNCTION "getOrder"()...
but then whenever I call it, I have to actually call it with the quotes, which makes that a pain for things like PHP.
Is there a way to simply tell postgres to leave the case of the method names alone? I know I can solve by calling it something like get_order, but I'd prefer to keep the casing the way I created the function.
No, there is no option to do that. It would break expected behavior badly.
My standing advice is to use legal, lower-case names exclusively and never have to worry about this issue. Be sure to read the chapter about Identifiers and Key Words in the manual.
When I return something of type Option, it seems useful to explain in the name of the function name that it is an option, not the thing itself. For example, seqs have reduceOption. Is there a standard naming convention? Things I have seen:
maybeFunctionName
functionNameOption
- neither seems to be all that great.
reduceOption and friends (headOption, etc.) are only named that way to distinguish them from their unsafe alternatives (which arguably shouldn't exist in the first place—i.e, there should just be a head that returns an Option[A]).
whateverOption isn't the usual practice in the standard library (or most other Scala libraries that I'm aware of), and in general you shouldn't need or want to use this kind of Hungarian notation in Scala.
Why would you want to make your function names longer? It doesn't contribute anything, as the fact that it returns an Option is obvious when looking at the function's type.
reduceOption is sort of a special case, since in most cases you really want to use reduce, except that it doesn't work on empty sequences.
If I only want to check if something is impossible or not (i.e., I will not be using something like if(possible)), should I name the boolean notPossible and use if(notPossible) or should I name it possible and use if(!possible) instead?
And just to be sure, if I also have to check for whether it is possible, I would name the boolean possible and use if(possible) along with else, right?
You should probably use isPossible.
Negative names for booleans like notPossible is a very bad idea. You might end up having to write things like if (!notPossible) which makes the code difficult to read. Don't do that.
I tend to err on the side of positivity here and use possible. It means someone can't write some code later that does this...
if (!notPossible)
Which is unreadable.
I like to name booleans with consistent short-verb prefixes such as is or has, and I'd find a not prefix peculiar and tricky to mentally "parse" (so, I suspect, would many readers of the code, whether aware of feeling that way or not;-) -- so, I'd either name the variable isPossible (and use !isPossible), or just name the variable isImpossible (many adjectives have handy antonyms like this, and for a prefix has you could use a prefix lacks to make an antonym of the whole thing;-).
I generally try to name my flags so that they will read as nicely as possible where they are being used. That means try to name them so that they won't have to be negated where they are used.
I know some folks insist all names be positive, so that people don't get confused between the negations in the name and those in their head. That's probably a good policy for a boolean in a class interface. But if its local to a single source file, and I know all the calls will negate it, I'd much rather see if (impossible && ...) than if (!isPossible && ...).
Whichever is easier to read in your specifc application. Just be sure you don't end up with "if (!notPossible)".
I think it's considered preferable to avoid using negatives in variable names so that you avoid the double negative of if(!notPossible).
I recommend using isPossible. It just seems to make a lot of sense to use 'is' (or perhaps 'has') whenever you can when naming boolean variables. This is logical because you want to find out if something is possible, right?
I agree that negatively named booleans are a bad idea, but sometimes it's possible to reframe the condition in a way that's positive. For example, you might use pathIsBlocked rather than cannotProceed, or rather than isNotAbleToDie you could use isImmortal.
You should name it for exactly what is being stored in it. If you're storing whether it's possible then name it isPossible. If you're storing whether it's impossible name it isImpossible.
In either case you can use an else if you need to check for both cases.
From your description it seems more important to you to check for impossibility so I'd go with isImpossible:
if(isImpossible)
{
// ...
}
else
{
//...
}