Google's Shell Style Guide

http://google-styleguide.googlecode.com/svn/trunk/shell.xml

by shawndumas • 13 years ago

227 185 13 years ago

google-styleguide.googlecode.com

thejosh• 13 years ago

Rest of languages here: https://code.google.com/p/google-styleguide/source/browse/tr...

hacker7892• 13 years ago

http://google-styleguide.googlecode.com/svn/trunk/shell.xml?...

It is not necessary to know what language a program is written in when executing it and shell doesn't require an extension so we prefer not to use one for executables.

I disagree with their recommendation against using file extensions for executables, and I'd love to have my mind changed about this.

Using an extension gives you automatic syntax highlighting. It also lets you quickly glean the type of a file when exploring a directory for the first time, which is more helpful than simply knowing whether the file can be executed.

Why does a lack of necessity override those two benefits?

flebron• 13 years ago

Your benefits are so to people who are going to be editing these files. They are not benefits to people who are going to be using these files (i.e. running the script). Most people are not going to be editing the script, they are going to be using it. Thus, it makes sense to cater to them, and to not have them have to know things they don't care about, like what language the tool they are using was programmed in.

jfb2• 13 years ago

Any serious editor will read the #! line for syntax highlighting, which has the benefit of being much more likely to be correct than the user visible and modifiable file name.

raverbashing10• 13 years ago

Except when it doesn't have that line because it's a C/C+header file.

And then the editor doesn't know what to do with that header file without extension. Yes, if you see some Google C++ code they do that

Really, horrible practice.

nsmartt7• 13 years ago

The extension is unnecessary for syntax highlighting. Shebang lines are supposed to be used for detecting the file type.

As for knowing the file type at a glance, I'm not sure how often I need this. I'm normally looking for the file by name anyway. If I needed to determine the file-type, I'd write a script to parse the shebang lines of executable files in the current directory and generate a list of the files with their hypothetical extensions (based on a hash/dictionary/whatever). I don't need that very often, so, for me, the trade is worth it.

xwowsersx• 13 years ago

I'm new to shell scripting and I'm clearly missing something basic. Why can't you use file extensions? This is saying not to use .sh for bash scripts and .rb for ruby scripts, etc?

packetslave3• 13 years ago

One reason: let's say you write tool 'foo.sh' in Bash. It does what you want and you move on to other things.

It's suddenly a year from now, and your foo.sh tool needs some new features, or is too slow to do the job any more because your requirements have changed.

You decide it's grown too much for Bash and want to move to Python for maintainability, or Go for performance, or C++ to link with some library you need to use.

Now you have to tell your team (and any other teams that have found your tool useful): "We only want to maintain one version, so don't use 'foo.sh' any more. You have to use 'foo.py' (or 'foo.exe' or whatever). Oh, and have fun changing all YOUR scripts and tools that reference 'foo.sh'!"

That's one reason.

dredmorbius7• 13 years ago

(This point is also made lower down).

When you run a program, your concern should be what it is called. Not how it is written.

A language-specific filename extension puts an implementation detail in userspace. If you run a binary executable, you shouldn't care whether it's written in C, C++, Fortran, or any other language (though source files, being used only by developers and compilers, generally do have extensions).

Worse: if you decide for whatever reason to change the implementation language, you're either forced to track down and change all references to the program name, or to retain the (now incorrect) filename extension for backwards compatibility.

And, as noted, magic(5) or the shebang line should correctly identify the file type and language for syntax highlighting -- if not, your editor is broken. Replace it with a shell script, "editor.sh".

file(1) will tell you the types of files in a directory with far greater accuracy than filename extensions can.

hacker7892• 13 years ago

That makes sense. I think of shell scripts as "things programmers execute", but that's obviously not always the case.

txutxu3• 13 years ago

We don't use to run grep.c, or ansible.py, or git.c, or gunzip.sh, etc...

explore a directory? file -i directory/*

I follow the same convention than Google, just that I use .bash for libraries instead of .sh (as they state the interpreter should be bash, I think they should apply my naming instead of .sh)

andrewkreid• 13 years ago

> ...One example of this is Solaris SVR4 packages...

I wonder what Google are using Solaris for, and if it's just legacy stuff.

tmallen2• 13 years ago

Google is likely supporting Solaris for customers or for users of their open source software.

arethuza• 13 years ago

Google appear to use Oracle Hyperion Financial Management for consolidated reporting and planning (search their job pages - they usually have ads) - I would suspect that this runs on Oracle boxes running Solaris.

zobzu3• 13 years ago

"Indent 2 spaces. No tabs." Well fuck it.

Thats the only coding style that remotely makes sense to me: https://www.kernel.org/doc/Documentation/CodingStyle

While I'm at it, half the justifications Google gives for the shell guide are inaccurate. Looks like a "overall people are used to this style so we're using it and we'll try to justify it without knowing why"

This is a much better guide:

http://devmanual.gentoo.org/tools-reference/bash/

Example: Gentoo's [[ ]] explanation actually makes sense.

amaks• 13 years ago

It really doesn't matter how many spaces or tabs, what's important is that all code and scripts are written in the same style, which greatly reduces time required to understand someone else's code. At Google, that's a norm.

apr• 13 years ago

It actually does, 2 spaces indents are hard to read, period.

fhd25• 13 years ago

Yup. After a decade of programming, the only thing I care about is consistency. Even the weirdest code style people can come up with is just fine in a clean, consistent code base.

Mildly surprised to see people arguing for specific tab widths...

mradmin• 13 years ago

Agreed, consistency matters most. Regarding whether it matters whether tabs or spaces are used, I've come to realise that I cannot control the tab length when viewing code outside of my editor (obviously!). So, let's say we have a 80 char line length limit. If I set my tab size to be 2 spaces, the line length is obviously going to be different to someone who sets their tab size to be 4 spaces. Just having the option to control the size of tabs means tabs should never be used as it will result in inconsistencies across editing/viewing environments. Also, when viewing code online, generally you have a limited viewing area. If you're using tabs, the length of the lines are generally going to be very long, and it's very difficult to view the code. In conclusion, if you care about things like line lengths (you should), and if you care about keeping your code in a certain and consistent format, the only way to manage it is with spaces, imo.

nsmartt7• 13 years ago

I've always been conflicted on this. It's simply untrue that more than 3 levels of indentation indicates bad code. For example, HTML, XML, and JSON often benefit from deeper levels of indentation.

Tabs have the benefit of having a dynamic size, so I could simply adjust the tab width within my editor. Spaces also do not play as well with editors. Unfortunately, browsers offer no means to change the width of tabs, so it's impossible to properly display code using tabs. This is especially frustrating when reading the source of a page indented using tabs. It would be much easier to read with spaces, but not as easy to read as if I were able to set tab width.

GuiA• 13 years ago

HTML, XML, and JSON are document description formats. For most programming languages, more than 3 levels of indentation is a red flag.

edoloughlin• 13 years ago

It's a pity that elastic tabstops never got any traction. it's a really nice idea: http://nickgravgaard.com/elastictabstops/

dscrd• 13 years ago

Real men and women indent by prime numbers.

robin_reala• 13 years ago

Sure they do, add this to your user styles:

pre { tab-size: 2; }

https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size

olau• 13 years ago

On tabs vs. spaces, read the old classic: http://www.jwz.org/doc/tabs-vs-spaces.html

tldr; don't use tabs.

I read that piece many years ago and thought who cares, but I've later changed my editor to never use tabs. He's right.

Tabs are nice in theory, but in practice you end up with garbled code. It's better to train yourself to get used to seeing code bases formatted slightly differently, just one of the things you have to get over, IMHO. Like camel notation version underscores versus dashes.

raverbashing10• 13 years ago

+1 for the kernel coding style

I can understand (grudgingly) 4 spaces for Python

But for C/C++ 4 spaces are awful. Maybe because C lines end up being longer?

Tabs, they exist. Use them

sdoering2• 13 years ago

My editor automatically converts [TAB] to four spaces. Works just fine for me.

pjmlp3• 13 years ago

Tabs should be abolished, it is a pain to edit source code full of spaces and tabs characters mixed everywhere.

Then the additional issue that everyone maps tabs to a different amount of space characters.

Only spaces can give a proper consistency without relying on external tools.

chetanahuja3• 13 years ago

Hah... if you think 2 space indents are bad in shell (and C++), you should try writing python with it (yes, google coding style, in a fit of madness, insists that engineers try to keep python blocking straight with 2 space indents. Remember, some of these hapless folks are maintaining large bodies of production python code (as opposed to itty bitty automation scripts).

tomlu• 13 years ago

Google mandates 4 space indentation according to this: http://google-styleguide.googlecode.com/svn/trunk/pyguide.ht...

tmallen2• 13 years ago

The Gentoo documentation is a programming guide and doesn't advise on style. The Google style guide doesn't explain [[ because it is out of scope.

anuragramdasan• 13 years ago

Totally. I love the kernel style over anything else. Even the GNU style for C isn't something I am very fond of.

Still there are some languages where 4 spaces indent is fine. But two is just horrible. Also I like tabs. Convert tabs to spaces in the editor and it works out pretty fine. 2 spaces is just too cluttery.

th3byrdm4n• 13 years ago

Gentoo is extremely thought out and over engineered. They seem to do most everything right. . . It's just so much work though.

Note also on the [[ ]] usage... you'll see that [[ ]] won't work for boolean algebra ie. '||' and '&&'

Shish2k4• 13 years ago

Why is this still a thing that people have to care about? Can IDEs still not automatically convert between company-style and personal-style?

(Sad that tabs solved that problem decades ago (by having a byte that means "+1 indent" instead of having to build some ascii-art that looks like an indent) but people screwed up the implementations so badly :( )

simias• 13 years ago

Proper indentation (tabs for indentation, spaces for alignment) is still pretty hard to configure in most editors in my experience. Even in emacs I had to install an external package to get it to behave properly (and it still breaks from time to time).

Failing that I'd rather people just used spaces and no tabs. Using tabs for alignment just means it's going to look fucked up everywhere else. At least spaces are consistent.

dredmorbius7• 13 years ago

There's a lot of fiddly bits.

And my IDE is called "vim".

Sometimes it's called "ed".

TeMPOraL• 13 years ago

It's fun how the "tabs vs. spaces" war is relevant only where it doesn't really mean anything.

See, most of the languages (I've seen so far) have a well-defined rule of identation. The thing you get when you do "select all, ident file" in your IDE / editor. At this point it doesn't really matter whether you use spaces, or 2-space tabs, or 4-space tabs, or mix, or whatever - there's only one way non-whitespace characters can be positioned, so it will (in theory) look the same on every editor after you reindent it.

The only place where the choice of tabs vs. spaces actually matters is when you want, for some reason, to break the default rules of identation for your language and position something manually. But in this case, there's no debate; tabs are not suited for precise, manual positioning. Only spaces will be guaranteed to make the code look the same everywhere.

wattengard• 13 years ago

Umm... No...

Yes, the IDE does this, but indent-length and tabs/spaces is mostly ALWAYS definable within the IDE's settings, and is more related to the IDE than the language you are currently editing.

valtron• 13 years ago

I am extremely annoyed when I try to click at the beginning of a line and I clicked a bit too far left and the cursor gets placed _before_ a space because spaces are being used instead of tabs.

delinka• 13 years ago

Thread's gotten too deep and wide to reply to everyone, so I'd like to vent right here at the top...

We have these machines that are meant to take the tedium out of our lives, let's USE THEM. Why do we not have tools that format things they way I like them? Who cares how the other team members like it? They can use the tool, too. Who cares how it's stored in your VCS? The tool should just be part of the workflow and format spaces/tabs the way I want them and maybe revert to a canonical format for committing to the repo.

Personally, I prefer tabs. I read code best when it's indented four spaces. But John wants to use two spaces in this code. And Ralph likes three. Holy Hell, don't make me wade through someone else's preferences to understand this codebase! Use tabs and people can set them the way they want. Yes, tabs are broken in many places (e.g. Objective-C methods can get so verbose that they need to wrap; convention is to wrap and align the colons; tabbing as far as possible and then spacing to fill breaks things when Ralph formats his tabs to three spaces; in this case, there is indeed a solution: tab to the start of the original line of code, and space to format from there ... but then the IDE has ideas of its own about what should be spaces and what should be tabs...)

Maybe you can read that code with only two spaces of indent, but I can't. I'm gonna need that reformatted to put a larger visual separation between scope changes or whatever required the indention. Rather than have this debate, a tool should be forged.

gbog2• 13 years ago

Disagree. Readability is not about 4 or 2 spaces, it is about strongly enforced convention that makes these typographic details literally disappear from the eyes of the readers. This effect is very noticeable in book publishing: if you ever notice the typography, the typographer failed at his task. It is the same in code, just file the rules and it will become your preferred guideline in no time.

And repeated experiences everywhere point to the fact that code text is already very hard to manage, very sensitive to alterations, misreading, etc. I'd rather remove layers and tools than add more.

Edit: obviously, readability is ask about convention when they are within the realm of sane acceptable conventions. And by everywhere I mean in teams where the loc count is above a few thousands.

taude• 13 years ago

This looks at it only from the context of the single dev's machine. I care more about the consistency of the source code that's checked into the repository and not getting false file diffs based on white space differences, and other formatting discrepancies. And for some reason, this seems harder than it should be.

I'd like to see a diff tool designed around this.

subsection1h• 13 years ago

  > Use tabs and people can set them the way they want.

If members of a team set tabs the way they want, how do they limit line lengths to 80 columns, which is a requirement that's specified in the Linux kernel coding style that was linked to in the comment you replied to?

lmm2• 13 years ago

Yes, tabs are broken in many places (e.g. Objective-C methods can get so verbose that they need to wrap; convention is to wrap and align the colons; tabbing as far as possible and then spacing to fill breaks things when Ralph formats his tabs to three spaces; in this case, there is indeed a solution: tab to the start of the original line of code, and space to format from there ... but then the IDE has ideas of its own about what should be spaces and what should be tabs...)

Which is the problem. If you think it's possible to make a tool to solve this, great - do it, I'll happily adopt your tool as a precommit hook and use tabs to indent everything (or go on using spaces - your tool would turn them into tabs, right?) But given that this problem has existed since the '70s and no-one has solved it, I'm inclined to think it's impossible. So I'll use spaces in the VCS, which means agreeing an indent width so that our diffs make sense (and I don't really care whether that's two or four, but it does need to be defined and adhered to across the team).

consultant23522• 13 years ago

"The majority of people prefer it this way" seems like the perfect justification for a coding standard. Consistency is way more important to me than perfectly matching up with some specific ideal.

e40• 13 years ago

That reference is the best I've seen. Thanks for that.

untog• 13 years ago

The sheer number of replies to this point is staggering, for what really ought to be a total non-issue in this world.

Someone needs to make some kind of GitHub integration that lets you download code using whatever esoteric formatting you prefer, then transform back to some given standard on commit. Then everyone can finally just agree to disagree and get on with life.

frozenport• 13 years ago

Whats wrong with tabs?

jfb2• 13 years ago

Nothing intrinsically, but there is value in consistency, and Google's decided on spaces. One of the rationales for these guides is to give the programmer a way to make a decision about questions where there is no single correct answer.

100982• 13 years ago

Well, sometimes I need to align my lines in a certain way (e.g., if function arguments are on multiple lines, I want them to align with each other). It's often impossible to do with tabs, because they are fixed width, so I have to add spaces. But when other people view my code, and their tab width is different, it all goes to chaos. That's why I prefer spaces over tabs.

jmillikin• 13 years ago

You're doing something wrong, then. Here's a block of dummy code indented with tabs; copy-paste it into your editor, change the tab widths, and observe that the indentation stays readable.

  void my_function(int some_parameter, int another_parameter,
                   int the_third_parameter) {
  	if (some_parameter != another_parameter) {
  		here_we_are_in_an_if();
  	}
  	function_calls_work_fine_too(some_parameter,
  	                             the_third_parameter);
  }

philsnow• 13 years ago

tab to the indentation of the previous line, then pad with spaces

    def foo():
    TTbar(asdf, zxcv,
    TTSSSSqwer, oiuy)

no matter what anybody uses for tab stop size, the alignment won't get messed up.

jeady• 13 years ago

Mostly consistency, but also because it's kinda funky when you have an 80 character line limit (also in the style guide). Tabs are one character but displayed as multiple.

laurent123456• 13 years ago

One possible reason is that if you copy a line with tabs from the terminal, you're actually going to end up with the tab converted to spaces in the clipboard. If you use spaces everywhere, you won't have this problem.

sounds3• 13 years ago

Coding in the terminal does have its drawbacks.

That can't be an argument for using spaces in code, right? Rather, the terminal should keep track of which parts of its display were generated by a tab character in case the user copies the output?

jamesaguilar• 13 years ago

Nothing that hasn't been said a billion times already -- and likewise for spaces. A fairly comprehensive overview: http://c2.com/cgi/wiki?TabsVersusSpaces. No, the clever people in this thread are not going to put the issue to bed for once and for all.

skriticos2• 13 years ago

I like how the golang team solved the issue. Ship a formatter in the core package. Discussion closed.

fhd25• 13 years ago

It's still an issue, but arguably one you only have when starting a new project. I have yet to hear a single reason for tabs or spaces that justifies changing the indentation for a whole established code base - unless it had inconsistent indentation to begin with.

bsdetector• 13 years ago

If you use tabs, then you cannot have a column limit because the line length changes depending on what the tabstops are.

In Linux they say tabs are 8 characters, which no they are not, so they can have an 80-column line limit. Anybody programming with a less than 8 character tab can't get the column limit right (the number of characters on a line changes with the indentation level).

Tabs are invisible characters that don't have a standard width so are always causing problems like this. They are used because many programmers use editors where they would have to actually press space multiple times to indent/unindent (ie bad editors) and because source control doesn't know when an indent change actually means something vs just being cosmetic.

rurounijones• 13 years ago

"It should be possible for someone else to learn how to use your program or to use a function in your library by reading the comments (and self-help, if provided) without reading the code."

I know a few "Use the source, Luke" people who will rage at that.

nsmartt7• 13 years ago

The best argument I've seen here is that methods should be black boxes. Comments should reveal the input, output, and side effects of a method. There are two compelling reasons for this:

- I can add to my own code, even if it's years old, without re-reading every line every of every method I need

- I can contribute to a code-base built by multiple people without reading every line they've written

sounds3• 13 years ago

That is a particularly useful approach in functional languages, where the function declaration itself is actually a fairly concrete guarantee of what the function will do.

Shell scripts are almost the complete opposite end of the spectrum:

Shell script functions are usually only created as a last resort.

Global side effects (creating temporary files, changing global system state, global variables, etc.) are what shell scripts are all about.

There are rare snippets of shell scripting that are different, using local variables and doing some sort of calculation, but that is the exception, not the rule.

While ideally comments would be prolific, poetic, and perfect, some commenting is always better than none and most developers have bad habits of not commenting their code, so pushing them gently in the direction of more, not less, usually works.

dmgd• 13 years ago

why would you need to re-read every line if you are looking at methods that have a single responsibility and that responsibility is clearly communicated through the name? (and parameter types/name, return types/names, in languages where some of those things are available)

jakejake• 13 years ago

When I read that and also the section about using spaces instead of tabs I immediately thought - uh oh, here comes the nerd rage!

bcoates• 13 years ago

I'm surprised there isn't more commentary on when and how to use external but standard or common commands like grep, sed, awk, perl, join, find, tar, parallel, etc.

It's one thing to use bash consistently everywhere but as a heavy multi-machine shell user I've been bitten by incompatible or missing external utilities more often than I care to admit. You might be surprised how many systems aren't using the GNU utilities, have them running in a weird mode or are using ancient versions of them.

Maybe Google is religious about keeping all their environments identical?

clarkm• 13 years ago

And when you bring OS X into the picture, guaranteeing portability becomes a nightmare, especially when it comes to scripts that have anything to do with networking.

js2• 13 years ago

Re: long pipelines, the guide suggests:

  # Long commands
  command1 \
    | command2 \
    | command3 \
    | command4

However, by ending each line with the pipe the continuation is implicit and the backslashes may be omitted:

  # Long commands
  command1 |
    command2 |
    command3 |
    command4

dredmorbius7• 13 years ago

Pipes, and logical operators (&&, ||) can continue lines in bash. I find it convenient, and generally clear, to break longer constructions using these operators with them.

emmelaich2• 13 years ago

I usually use the trailing | but I can certainly see the sense in the leading pipe.

It makes it clearer that the lines following are continuations; especially the last in the pipeline.

sesqu6• 13 years ago

I consider the leading pipe clearer, and could be sold on it, but ending each line with an inconvenient slash character (non-US layout) makes me strongly favor the trailing version.

The trailing version seems more natural with operators like comma, but less natural with operators like minus, and is far clearer with semicolonless languages. I suspect if I were to go through old code, I'd find both uses, but generally I prefer trailing.

The exception to this is languages like Haskell, though indentation could serve the same purpose.

dredmorbius7• 13 years ago

Some things I don't particularly care for (2 space indent? SRSLY?!!), but it warms the cockles of my heart to see an 80 character line limit.

Yes, it matters.

fhd25• 13 years ago

Yeah, Google has 80 column limits for almost every language (except for Java, it's pretty difficult there). So does Mozilla and all major open source projects I can think of (again, Java being the exception).

It really does a lot for readability. I recently summed up my reasons for doing it in all of my projects: http://ubercode.de/blog/80-columns

dredmorbius7• 13 years ago

The argument-ender for me is: Look, when I'm at the DC, on console, with an 80 column screen, I cannot make my terminal any wider than 80 characters, and the site is down.

This also applies for a lot of remote-access tools -- serial console as well as direct, so even if I'm not at the DC, once I'm on those interfaces, something's likely fucked up or headed that way.

barrkel• 13 years ago

An 80 character line limit almost mandates use of a 2 space indent, for most languages.

Personally I prefer a line limit closer to 100, and 4 space indents in most languages. Some languages end up with a lot more indenting than others owing to structural literals and lambdas, and they benefit more from a smaller indent.

dredmorbius7• 13 years ago

I manage 80 chars (with very few exceptions) and a 4-space indent. Copious use of bash functions helps.

abecedarius• 13 years ago

I'm happy with 80 columns and 4 spaces in C, Python, etc. Don't see the mandate. 2 spaces would make reading harder.

__david__• 13 years ago

Not me. Limiting your code to 80 characters is stupid. Code != prose and you read it differently, so the prose rules don't follow.

Skinnier prose is easier to read because of the sequential nature of it, which is why I do think comments blocks should be limited to 80-100ish characters. But code? No.

emmelaich2• 13 years ago

The most important point:

    Shell should only be used for small
    utilities or simple wrapper scripts

rat87• 13 years ago

Unfortunately firefox 24(on windows) has problems with rendering the style of the xsl stylesheet and gives crap putput(Basically the full text content with no line breaks). It seems to work on firefox 21/linux though. Also ie8/windows and chrome 30/windows chromium 25/linux work.

AYBABTME• 13 years ago

Thanks for `go fmt`.

ushi• 13 years ago

I had the exact same thought. The Go community is the only one (i know), where such discussions are rare.

Write your code, run "go fmt", add, commit.

eriksank• 13 years ago

These rules look like they came from the low-intelligence paper belt. We do not write rules like that. They must simply be part of the tool. Otherwise, they do not count. What they now did, was to create an opportunity for someone who knows that he is incompetent, to invent a new job for himself, that is, "checking up" with his more competent colleagues, who contrary to him are productive in writing code, on this style guide. Rule number one: Anybody who wants to "enforce" this kind of rules must demonstrate that he is capable of writing a parser that can apply them. It is simply bad practice to create that kind of opportunities. It is bad practice to create that kind of jobs. Therefore, this kind of documents must be rejected.

CraigJPerry• 13 years ago

I think that's a bit harsh.

Of course we write style guides and while I like the idea that it's part of the tool, that's rarely the case.

I don't follow the objection about a colleague helping ensure consistency across a team. I'm really not sure why competence comes into that equation either.

Agree with the idea any style guide should be automated. Several CI servers I know of can incorporate style checkers and their reports into their workflow so this can be made really hands off, even to the point of automatically failing code review stage before its been lumped in the review queue.

Don't agree at all with the idea this type of doc should be rejected. In fact it's completely wrong to jump into automation without having "found which way is up" manually first time around.

Shorel7• 13 years ago

Actually, they came from very smart, well intentioned people, who thought everyone would program Lisp in this century. And of course never saw C (and all its related family of languages) coming and ruling for decades.

All these rules make sense for Lisp, and no sense at all for C.

And they did wrote the parser that applies those rules, in Emacs you never indent Lisp code, you press a key and the current s-expr automagically indents better than you could ever dream of doing it.

MichaelMoser1233• 13 years ago

I almost always use set -e with my bash scripts; this way you will always notice if an invoked command failed or not; your script will not report that everything is OK if part of the process actually failed.

https://www.gnu.org/software/bash/manual/html_node/The-Set-B...

Also: set -x is the best debugger in the world; really.

MichaelMoser1233• 13 years ago

Also useful trick is to have exit traps, doing stuff on exit.

http://linux.die.net/Bash-Beginners-Guide/sect_12_02.html

penguindev• 13 years ago

Yeah, surprised that got no mention.

I thought the ./* wildcarding for safety was really cool. they also could have covered find -print0 | xargs -0 for safety.

I'm glad they talked about "$@" being usually always the right thing to do. That's been a hard won learning experience for me in the past...

pirateking• 13 years ago

Style guides are the worst to me. Taking some of the small joys left in programming away, while making you feel like a cog at the same time. Especially since many are outdated or just plain wrong, and very difficult to change once established.

Tools that take the AST and output standardized code for peer review and documentation sounds a little better. It would not deal well with the only human problem really worth having a style guide for - naming things. But at least humans aren't forced to jump through hoops. And the naming thing possibly can be settled with an interface that asks something like - "what do you want everyone to call the 'BitWarper' symbol?", for all named symbols.

But well written software is no place to express individuality - we just want it to work and not make our eyes bleed when we have to fix it! Even better then, just have machines generate and test all the code based on systems of higher order rules and style guides in situations where factory manufactured code is necessary. The outputs should be reasonable if the requirements are well specified (NASA style). Humans can come in after and do the real fun work in optimizing and finding clever hacks (if environment is not mission critical and such liberty can be safely taken).

Having humans program character by character, with their bare hands, while also suppressing creativity, is unnecessary in this Post-Industrial Age.

jebblue• 13 years ago

i'm going to have to bookmark this site, I'm no Bash expert but with some Bash and Java and a bit of Python here and there, sometimes I feel like I could save the world.

txutxu3• 13 years ago

I've seen many scripts wrapping steps inside a main() function and calling it just after declaration.

If the justification is to localize variables which should be global, and still will look like "global" to the rest of the program, it's ok.

But this is mainly used without sense, by personal tastes, and usually only makes sense to the author and does not have any real benefice.

I prefer the concept "consistency is to not read unuseful steps", instead of "add unuseful steps for consistency". That's how I think when I read code.

txutxu3• 13 years ago

Other one from the summaries:

I don't see how

    $((${X} + ${Y}))

... is more recommendable than ...

     $(( X + Y ))

for example.

But well, guide styles are a good thing, and this one can help to many people "not used" to deal with shell scripts to follow some basics.

Edit: and help to people used to it, on working in a team.

rainhacker• 13 years ago

Under the section 'When to use Shell', why does the style guide say 'If performance matters, use something other than shell' ? I was under impression that since shell script is low level it should have superior performance.

Google's Shell Style Guide

Related Stories