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.
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 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.
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
I'm re-evaluating SONAR code quality rules after upgrade to 4.4 and here is strange CheckStyle rule called 'inner type last' which is part of class design group and actually recommends to place inner classes AFTER everything including methods.
What motivation is behind this? I never expected someone to consider this approach as useful but maybe I have missed serious ideology? Checkstyle rule definition doesn't provide any ground neither quick googling (maybe I searched wrong way). Could you please point from where this comes?
This rule assumes that inner types are "side" types that deal only with internal details of the enclosing type, and so that it's not worth showing those details at the very beginning of the source file to not focus attention on them.
IMO, the only (very little) value of this rule is to ensure consistency of code structure across your source code.
Well ... this is indeed a mostly useless rule, especially because it cannot currently (5.7) be configured to enforce inner classes being declared at some other position than at the end. It can safely be disabled, I think.
However, it is the only way to enforce this part of the source file structure, so if you cannot be sure that everybody has her/his formatter properly configured, you might even want this. (Personally, I prefer inner types at the top, so that I know what they are when I read the code that's using them.)
The Checkstyle rules were originally focused on the Sun Code Conventions (1999), which did not say where inner classes should go. Also, the newer and popular Google Java Style (2014) has no opinion on this. Checkstyle even has a DeclarationOrder check, which also cannot check inner class position.
So I guess someone finally said this had to end and added InnerTypeLast. And there we have it. :-)
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 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 4 years ago.
Improve this question
In API documentation, and sometimes even used in discussions here on Stack Overflow, I sometimes see the pound (#) character used instead of the dot (.) as the separator between the class name and the method name. For example:
Settings#maxPageSize
I'm wondering what this usage means, and where it comes from?
Assuming you mean Ruby (which is the first language that I can think of with such conventions), it is explained here:
Why are methods in Ruby documentation preceded by a hash sign?
I've always thought that the distinction is that Settings.maxPageSize seems to imply that you can actually write just that (i.e. that it is a static method), and that the pound is there to denote that it is just a reference to a method, not a piece of code that you can execute.
Although I could be totally wrong about this =)
So for static methods, you could actually reference them Settings.maxPageSize, but for instance methods, you'd have the option of coming up with a new convention, such as Array#sort to denote that something special is going on, or, to achieve the same completeness, you'd have to write
myArray.sort // when myArray is of the type Array
EDIT
Amadan's reply seems to confirm my interpretation, with the exception that Settings.maxPageSize is not used for static methods either; rather, that would be Settings::maxPageSize, and . being reserved entirely for example code, which makes sense to me.