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 3 years ago.
Improve this question
I read a bunch of the articles a questions asking about capitalizing SQL keywords (SELECT, FROM, WHERE, etc.), but I couldn't find a thread for the following:
Should I capitalize SQL functions, like SUM(), COUNT(), etc.? The teacher of a class I took used to capitalize the functions, but a software engineer at work told me not to.
Is there a convention?
In short, it really comes down to personal preference/style. It's a traditional convention that's been around for ages to always use upper case letters for reserved words in SQL (see here: https://www.sqlstyle.guide/#query-syntax) and the idea is that even if someone is not using an IDE that highlights the reserved words, they can still easily differentiate between the reserved keywords and other stuff such as column and table names.
Personally, I think capitalizing the reserved words just makes the SQL code look like it's from 30 years ago and constantly using shift or caps lock while typing is just not something I want to do. There are auto-formatting extensions that you can use but honestly...why?
Yes, capitalizing SQL statements is a convention and I strongly suggest to use it. Like others wrote in this thread it really helps with reading scripts (you will see that they can be really big).
T-SQL conventions from MS: link
From what I've seen it is personal preference, but it will have no effect on how your query runs. I do because I think it makes the query more readable, but if your team does not want you to then you shouldn't.
I use SQLPrompt extension which corrects what you type to UPPER case when needed by convention.
Yes, COUNT(), SUM() and other functions are capitalized by SQL Prompt.
Related
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
I want to which is, in your opinion, the best practice for name SQL columns.
Example: Let's say that i have two columns name referenceTransactionId and source
now there is another way to write this like refTxnId and src
which one is the better way and why? Is it because of the memory usage or because of the readability?
Although this is a matter of opinion, I am going to answer anyway. If you are going to design a new database, write out all the names completely. Why?
The name is unambiguous. You'll notice that sites such as Wikipedia spell out complete names, as do standards such as time zones ("America/New_York").
Using a standard like the complete name means that users don't have to "think" about what the column might be called.
Nowadays, people type much faster than they used to. For those that don't, type ahead and menus provide assistance.
Primary keys and foreign keys, to the extent possible, should have the same name. So, I suspect that referenceTransactionId should simply be transactionId if it is referencing the Transactions table.
This comes from the "friction" of using multiple databases and having to figure out what a column name is.
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 4 years ago.
Improve this question
Let there be class Foo which has method isUpToDate(). The method is called multiple times in the application, and when called, is always inverted. I.e., if(!foo.isUpToDate()) { ... }. If the method is refactored to isNotUpToDate() (to avoid putting ! on every call), would it be a good or bad practice?
Edit: To avoid only-opinion-basis, could someone share a reference to some respectable source?
I usually recommend not to use negation in a function name. This is because double negation can become hard to read.
If you use Not in your function name, here is how you would check something is actually up to date.
!foo.NotUpToDate(...)
Thus by trying to avoid negation, you opened the door to double negation; this is bad.
To avoid double-negation, write functions and methods that check the positive statement and use your language not operator.
Like Olivier Melançon said using Not in a function name is not recommended because of double negation. If you only use the inverted form there is usually a better name for the function.
In your case i would suggest using something like NeedsUpdate(...) or IsDirty(...)
No it is not. you should write code in a way that is more understanding and self explained so when someone else(or even yourself after sometime) just just look at your code (even without reading the code documents) he will understand that foo.isUpToDate() determine whether the class is update or not. using ! is not something bad and i guess isUptoDate less confusing than isNotUpToDate However it is up to you.
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 7 years ago.
Improve this question
I am deploying an application at one of our vendor. We have few special character that needs to be removed using a function. Vendor is really slow with any changes that we request.
I have access to one of the configuration table that we use to save configuration table.
I want to save a SQL function in the table column that I will fetch at run-time and will execute it.
I am not sure if its a good programming practice. Please suggest if this should not be used then why or is there any other way to do it?
Database is SQL Server. Suggest if it's a good programming practice.
A better practice would be to write your function in such a way that you don't have to change it every time a new special character pops up.
Instead of writing a function that filters out a predefined set of special characters, why don't you write a function that allows a predefined set of non-special characters? Then you should never have to change it.
you can use a Computed column in sql server, for me it's not a good practice depending on the scenario that you are trying to achieve but I think this might help you
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 9 years ago.
Improve this question
I just started to learn PDO and i read that in prepare statements you can use named parameters and question marks parameter. So which should i use, or they are completely the same and is just the matter of my decision which to use? Becuase i saw more people choose to use question mark parameters.
As a matter of fact, question marks produce dramatically shorter code.
Being not a novelist but programmer, I prefer concise code like this
$stm = $pdo->prepare("SELECT id FROM table WHERE name=? and pass=?");
$stm->execute(array($name,$pass));
$id = $stm->fetchColumn();
while named placeholders will require me to write every name a dozen times.
But anyway, it's indeed only a matter of personal preference.
You can use both, but using "named parameters" is (for obvious reasons) a lot easier, and more clear.
A good thing about named parameters is that you can see in your code what variable is inserted where in the query, and adding pieces of code (later on) is easier because everything has a name and is not depended on the order of the parameters.
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 8 years ago.
Improve this question
What do you prefer to use and what is the best practice - to make long but very meaningful names or to make shorter ones?
For example, if you are writing a class House, will be
int numberOfRooms;
or
int nRooms;
Sure, long names are better for understandig when you read foreign code or give yours to somebody, but they make code longer -> more complicated to read. So I messed up with it. :)
One of the most important things is understanding code.
It's better to name the variable numberOfRooms or numOfRooms than nRooms - nRooms could mean something else and numOfRooms is just 4 characters longer - so, I think, it worths to name it a little longer.
Use the house naming style for wherever you are working. Other colleagues will be maintaining your code in the future and it is best to make it easy for them.
If you are working for yourself then use the standard naming style for the language you are using. Delphi, Java, C# and others all have standard styles.
If you are working on a collaborative project then follow the house naming style for that project.
As Miroslav says, longer names are generally better, within reason.