Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
In the Ruby community "everyone" is using spaces (mostly two spaces) for indentation. Since I prefer an indentation level of four spaces I use tabs instead. I think tabs are great because they let the editor show your preferred indentation level. Those who want to read my code with an indentation level of two spaces can easily do that without modifying the file.
But clearly I'm missing something obvious here, since nobody else is using tabs for indentation. For example, these guidelines recommends you to never use tabs, since they "include the practice of mixing tabs with spaces"(?) I can't remember that I have done that a single time in my whole life.
Does anyone else got better arguments for spaces? There has to be, since everyone is using them.
You need both tabs and spaces if you want to do something like this:
def foo:
bar(some, long, argument, list,
continued, on, another, line)
You can use a tab at the beginning of the "bar" line, and another at the beginning of the next line, but then it has to be followed by 4 spaces to make sure the arguments line up (if you used a tab, they would no longer line up with different tab widths). This works perfectly, but mixing tabs and spaces makes people afraid of introducing mixed indentation in the same file, and so often they decide to standardize on spaces alone.
Many editors will let you keep typing tab while inserting four spaces at onces, and handle backspaces as if you had typed a tab, so it works the way you're used to.
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 6 months ago.
Improve this question
I have read the Indentation style entry on Wikipedia, but it's not very clear.
For K&R style, it says:
each function has its opening brace at the next line on the same indentation level as its header
Multi-line blocks inside a function, however, have their opening braces at the same line as their respective control statements
For the 1TBS (OTBS) style, it says:
functions have their opening braces on the same line separated by a space
It didn't talk about classes at all, but the Java style did:
the opening brace is on the same line not only for the blocks inside a function, but also for class or method declarations
If I am following the 1TBS style, where would the opening brace be placed for a class definition?
I also did a lot of searching (I prefer obtaining an answer immediately, instead of asking a question and waiting a long time), but no result.
There is unlikely to be an objective answer to this, as both the K&R and 1TBS styles emerged in the context of the C programming language, where there were no class definitions.
Since derivative languages of C that support classes (e.g., C++, Java, etc.) share most of the syntax, it is only natural that the brace-style conventions that emerged for C would be used in and adapted for these derived languages. But they would be precisely that—derivations and adaptations. This is why the Wikipedia article mentions "Java" as a "variant" of the K&R style.
There is no right place or wrong place to put the opening brace for a class definition, even when following K&R or 1TBS styles, since classes aren't part of either of those two styles. Inevitably, you'll be following some variant of those original styles that includes a convention for class definitions, and, in a variant, any convention you choose is valid.
Ultimately, it matters not. Write the code in the way you think is readable (if you're writing it from scratch) or in the way that conforms to the other existing code files in the project. Conventions are merely that: conventions. There's no objective answer, and it doesn't matter.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
The community is reviewing whether to reopen this question as of 4 days ago.
Improve this question
I am happy and really like the Ctrl-R backward search feature of the bash shell. Some of my colleagues don't like it, since it is sometimes confusing. I understand them. If you enter the wrong characters, the current position in the history is somewhere in the past, and you won't find the recent matches.
Is there a more user friendly alternative for seaching backward in the shell history?
I want to stick with bash. Suggesting an alternative shell is not an answer to this question.
The issue with the "lost position" is explained here: Reset bash history search position These solutions work. That's right. But the solution there are not easy and user friendly according to my point of view. These solutions are not simple and straight forward. These are solutions of the past. In the past the human needed to learn the way the computer wanted the input. But today the tools should accept the input in a way which is easy for the user.
You can also use history-search-backward. It's not bound to any key by default, so you need to add
"\eq": history-search-backward
to your ~/.inputrc. Then you can type a prefix of the command you want to find in the history, e.g.
cd /l
then press Alt+q and the shell will expand it to
cd /last-visited-dir
Pressing the key combination again will search for a previous mention, etc.
If you type the wrong characters to search for, press Ctrl-G to stop the search and then Ctrl-R and the correct characters to restart the search.
You can also set up Ctrl-S to reverse the direction of the search in case you entered the correct search characters but went to many steps backward. The Ctrl-S allows you to go forward. To enable this, you will need to add:
stty -ixon
to your Bash startup file.
That command turns off the default flow control function of Ctrl-S and Ctrl-Q and makes those key combinations available for other uses. In Bash by default Ctrl-S is used for history search and Ctrl-Q is a duplicate of Ctrl-V which performs quoted insert (e.g. pressing Ctrl-V Enter results in ^M being inserted as a representation for the single character for Return).
And you might need to add:
"\C-s": forward-search-history
to your ~/.inputrc.
Piping history through grep gives you a "less interactive" way to interface with the history buffer, but sometimes less interactive is what you need.
You can re-execute a specific numbered command from the grep output with !number
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
Is it possible with bash (or maybe even zsh) to use a character other than the tilde ("~") do designate one's home directory? For example, "cd ~" takes you to your home directory. Hitting the shift key with my right pinky and then ~ key with my left pinky simultaneously has always seemed very awkward to me, particularly since it's a keystroke combination that's used so much. Is there another way to do this? I don't want to have to type $HOME all the time either. Ideally, I'd like to be able to use something more natural like shift+$ or shift+% instead of shift+~. Can this be done? By the way, I'm not looking for a shortcut such as "cd" to get back to my home directory. I want to make it easier to get to directories beneath my home directory.
Just use cd without arguments to go to the HOME directory.
See man bash
You can remap backtick ` to tilde ~ in Bash. With a US keyboard layout, this saves you a Shift:
bind '"`": "~"'
This only affects the shell prompt, and has the additional benefit of reminding you to always use $(..) over deprecated `..` for command substitution.
Several proposals that cannot work:
"shift+~" is just a symbol, not some weird metakey-combo!
"shift+%" gives a '%', which is already reserved for job
control
"shift+$" gives a '$', which is already reserved for variables and spawning child processes as in '$(cat blah)'
Some ideas that might work:
Instead of using $HOME, define $H in ~/.bashrc. That's only 2 characters, and $ is much less complicated to type
If it's your computer, you could create a symlink '/h' that points to your home directory, so that you could type /h/foo/bar instead of ~/foo/bar.
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 8 years ago.
Improve this question
I have a piece of code that generates a pretty long SQL statement, with some dynamic elements to it. This code has been written from the formatted query that I wrote as a parameter to my database querying function: Up to whitespace, the two queries are exactly the same. Indeed, if I copy the generated SQL and apply :%s/\s\{2,}/ /g to it in Vim, the output is identical to the original query (comments removed), with :%j followed by :%s/\s\{2,}/ /g applied... However, the queries produce different outputs!
Actually, they produce different outputs some of the time. When I tried investigating this in my querying tool, the VBA-generated SQL still didn't work as expected, whereas the original did. When I applied the above whitespace-removing transformations to the VBA-generated query, it did work; but what's weird is that the originally generated query (with the extra whitespace) suddenly started working! However, it's inconsistent: there's no deterministic pattern (under my control) that will guarantee the extra whitespace version to work. (My guess is that this may be a caching phenomena, courtesy of the database server.)
Anyway, I guess my question concerns whitespace: I was always under the impression that whitespace was irrelevant to SQL, beyond delimitation. Is this not the case, or is something else going on here? Maybe the generated SQL string is too long (> 6kb)... Any ideas?
One idea to make the query less complex from app perspective is to take the complex part and bury it in a view, then from app, just
select c1,c1, ... from myview;
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
Should the name of command line options for a program in a POSIX-style operating system be underscore-style, like
--cure_world_hunger
or maybe some other style?
--cureworldhunger
--cure-world-hunger
--cureWorldHunger
What's most common? What's better style? What's more Bash-friendly (if such a thing exist)?
Underscore is not a good idea, sometimes it gets "eaten" by a terminal border and thus look like a space.
The easiest to read, and most standard way is to use a dash:
--cure-world-hunger
Always hyphens! Let's get a reputed reference: the Gnu style guide:
GNU adds long options to these conventions. Long options consist of
‘--’ followed by a name made of alphanumeric characters and dashes.
Option names are typically one to three words long, with hyphens to
separate words. Users can abbreviate the option names as long as the
abbreviations are unique.
Another problem with underscores is that if the documentation is linked in a HTML document, the link underline will hide the underscore and will confuse the user.
The double dash prefix is a GNU convention I believe. Check out getopt_long(3) man page on the GNU/Linux Operating System.