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 in a process of refactoring some unix shell scripts
and find many inconsistencies and different styles in our code
For example:
somevar="${item1},${item2}"
somevar=${item1}","${item2}
somevar="$item1,$item2"
Is there a coding style guide for unix shell scripts? or a formatter like clang-format for C++
[Edit] Please note I am not asking for personal style preferences or personal opinion! I am looking for an industry standard document, a widely used style guide or a popular tool.
I've worked in a few companies that have their own style guides but most now use Google's style guide. If you don't have a home grown style guide then Google's is good and is published here: https://google.github.io/styleguide/shell.xml
I personally check my shell scripts with the shellcheck plugin for vim but it's available on the web and for other editors. You can use it and get the downloads here: https://www.shellcheck.net/
Since word splitting won't happen in the context of a variable assignment you could just use:
somevar=${item1},${item2}
I personally prefer to use
somevar="${item1},${item2}"
The quotes doesn't hurt and - imo - increase readability.
About ${var} vs. $var. That matters when the variable name may contain an underscore, like "$foo_bar". What does it mean? The variable $foo plus the literal string _bar? Or the expansion of the variable $foo_bar? I would consequently use ${var} to avoid such situations.
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.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
One of the ways to write a multi-line string in Ruby is the "here document", or "heredoc", with syntax like:
<<~HEREDOC
My multi-line string
literal goes here!
HEREDOC
My understanding is that any identifier (word) can be used in place of where HEREDOC was used in the above example. (It doesn't have to be the word HEREDOC.)
Is there a documented best practice -- for code readability, and conformity to standards -- for choosing the name to use in a heredoc declaration?
Observations I've made:
The official documentation (as of Ruby v3.0) doesn't seem to advocate any particular best practice. It just states:
You may use any identifier with a heredoc, but all-uppercase identifiers are typically used.
The word SQL seems common when defining a SQL statement -- regardless of the purpose of the statement.
Code examples (including in the official documentation, and in the canonical StackOverflow question on multi-line strings in Ruby linked above) often use HEREDOC, or EOS (presumably meaning "end-of-string" -- even though the identifier appears both at the beginning and end of the string literal).
Sometimes, a word describing the value being stored is used as the heredoc identifier -- as is typically done when declaring a standard variable.
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 have been learning AWK in my UNIX class, which has been really fun; but I have been wondering how useful my AWK skills will be in a future job environment. It seems that text formatting is something that does not generally need to be handled on the command line in the way something like a shell script task necessarily would. Also, are potential employers going to care whether something esoteric like AWK is on my resume?
I have been learning AWK in my UNIX class, which has been really fun;
but I have been wondering how useful my AWK skills will be in a future
job environment.
If you are expecting to work in a field related to systems administration or even software development on Unix-like platforms, knowing AWK can be incredibly useful. It is a standard tool in many shell scripts.
It seems that text formatting is something that does not generally need to be handled on the command line...
Well, AWK isn't really about text formatting. It's about extracting data from text streams.
Also, are potential employers going to care whether something esoteric like AWK is on my resume?
Not at all. They may care that you are able to competently write shell scripts, but it's not something that will be called out explicitly. It's such a basic skill that listing it on your resumé would look like padding.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I want to write bash in a comfortable environment.
I've tried http://www.vim.org/scripts/script.php?script_id=365
But it lacks:
function list
function parameter hint
function description hint
Is there any vim plugin which you use when writing shell script?
Don't forget that Vim is not an IDE (though through its great integration capabilities and plugins, it can appear like one). It is first and foremost a (very powerful) text editor. (There are various blog posts and discussions around that topic, so I spare you further arguments.)
How are function parameter hints supposed to work in Bash scripts? Arguments are simply passed as positional untyped parameters $1 etc., and must be parsed and assigned to variables inside the function.
Likewise, a function description would require some sort of commenting conventions (e.g. tags like Doxygen or Javadoc use); this is not generally used, so don't expect an existing solution.
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'd like to write a code beautifier and i thought of using Ruby to do it. Could someone show me a place to get started? I've seen a lot of code beautifiers online but I've never come across any tutorials on how to write one. Is this a very challenging task for someone who's never undertaken any projects such as writing a compiler, parser, etc. before?
(Is there another langauge which would be more well suited for this kind of task, excluding C/C++?)
Python has an interesting feature - it exposes its own parser to scripts. There are examples that use the AST - abstract syntax tree - and do the pretty printing.
I'm not aware that Ruby exposes its own parser to its scripts in such a way, but there are parsers for Ruby written in Ruby here.
Well... I think the initial steps are what you'd do for any project.
Write a list of requirements.
Describe a user interface to your program, that you like and won't prevent you meeting those requirements.
Now you can write down more of a "code" design, and pick the language that would be easiest for you to meet that design.
Here's some requirements off the top of my head:
Supports code beautifying of these languages: Ruby, Python, Perl
Output code behaves identically to input
Output has consistent use of tabs/spaces
Output has consistent function naming convention
Output has consistent variable naming convention
Output has matching braces and indentation
Make as many as you want, it's your program. ;p I was kidding about the Perl, but I think every language you support is going to add a more work.
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.