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
Note: I'm not sure if this is the right place for this. If another site suits this question better, please point me there. I was going to place it on cs.SE, but there was no tag about formatting, so I figured it didn't belong there, and this isn't actually runnable code, so I figure it doesn't belong on codereview.SE either.
When I was first taught to program in Java in 2009, my teacher (and all the examples from the book) had the code formatted as such:
public void method()
{
if (condition)
{
doStuff();
}
}
However, in the field, I rarely, if ever, see it like that. Almost always, it's like this (whether or not it's Java code):
public void method() {
if (condition) {
doStuff();
}
}
Why do so many programmers choose to put the curly braces on the end of a line instead of their own line? Is it to save scrolling length or file size? Perhaps it was the standard before my education? To me, it just makes it less clear whether we're entering a new block.
Of course, I can chock up doing things like how many spaces to indent or adding spaces within parentheses, like if ( condition ), to personal preference, since it's not done nearly as often, but placing the brace at the end seems to happen way too often to just be personal preference.
My personal preference matches your first example, but I agree the same line curly brace is exceedingly common.
The reason (as I understand it) is that the same line format was the style in the original Kernigan & Richie (K&R) book The C Programming Language.
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 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.
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 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.
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 5 years ago.
Improve this question
I am trying to make a flowchart of my program (yes I know it is the wrong order to do it:) )
and I made a desicion symbol to represent the actionsheet I display in the iPhone application. It prompts the user "Yes, No, Cancel", so it is three options. However on all the templates/tutorials I have seen they only use "Yes" and "No" over the arrows which lead out from the desicion symbol. So could I use "Cancel" as well? If not how could I have done it otherwise?
You can do whatever you want with it, as long as it simplifies the meaning for your program. Decision making isn't restricted to 'yes' and 'no'.
Most of the time, flow charts are used to explain program logic to non-programmers. Your goal is to get them to understand what you program. We often use visual tools for this. You want to put all relevant information on there. If the cancel button is important to your program, put it on there. In my opinion there is no strict rule about what a flowchart should look like. Over time some basic form of flowchart has grown but you can add or remove whatever you want if it allows you to make more comprehensible charts.
Wikipedia suggests that decisions can have more than 2 choices, but should maybe be broken down. I see two options using a Google Docs drawing:
https://docs.google.com/drawings/d/11AhEIUOr9SdhXB1REculUy0NF9c628qaxfYVacUGfzU/edit?hl=en_US
I agree with the previous answer that the simpler it looks the better... whatever makes it most understandable. I think it's simpler to have 3 choices out of the 1 decision.
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 5 years ago.
Improve this question
Suppose that you are writing or maintaining a piece of code that uses some API that you are not 100% familiar with.
How do you decide whether to read the documentation of a certain call target, and how much time to spend reading it? How do you decide not to read it?
(Let's assume you can read it by opening the HTML documentation, inspecting the source code, or using the hover mechanism in the IDE).
Ideally you should read all of it, but we know that's a pain in the... you know. What I normally do on those cases (and I did that a lot while I worked as a freelancer) is weight some factors and depending on the result, I read the docs.
Factors that tell me I shouldn't read the docs:
What the function does is easy to guess from the name.
It isn't relevant to the code I'm maintaining: for example, you are checking how some code deletes files, and you have some function that obviously does some UI update. You don't care about that for now.
If debugging: the function didn't change the program state in a way meaningful to the task at hand. As before, you don't want to learn what SetOverlayIcon does, if you are debugging the deletion code because it's dying with a file system error.
The API is just a special case of an API you already know and you can guess what the special case is, and what the special arguments (if any) do. For example, let's say you have WriteToFile(string filename) and WriteToFile(string filename, boolean overwrite).
Of course, everything depends on the context, so even those rules have exceptions.