Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unnecessary style recommendation: semicolon after the last statement #1477

Closed
AlexDaniel opened this issue Aug 29, 2017 · 8 comments
Closed
Labels
docs Documentation issue (primary issue type)

Comments

@AlexDaniel
Copy link
Member

https://docs.perl6.org/language/syntax#Separating_Statements_with_Semicolons

A semicolon after the final statement (or after the final statement inside a block) is optional, though it's good form to include it.

What is meant by “good” here? Why? Can't we just end the sentence on “is optional”, without giving unjustified recommendations?

@AlexDaniel AlexDaniel added the docs Documentation issue (primary issue type) label Aug 29, 2017
@coke
Copy link
Collaborator

coke commented Aug 30, 2017

This was probably meant as more of a style suggestion: same reason you'd end a multi-line list with a comma when you don't have to, to prevent yourself from adding code at the end and getting a compile error.

But that can go in a style guide. Feel free to modify this as described.

@coke
Copy link
Collaborator

coke commented Aug 30, 2017

(Note: not OUR style guide. more like a "best practices" thing if someone wants to make one.)

@smls
Copy link
Contributor

smls commented Aug 30, 2017

FYI, moritz once started a "Well Thought-Out Practices for Perl 6" document here:
https://github.com/moritz/perl6-wtop/blob/master/practices.pod

@AlexDaniel
Copy link
Member Author

AlexDaniel commented Aug 30, 2017

same reason you'd end a multi-line list with a comma when you don't have to, to prevent yourself from adding code at the end and getting a compile error

It's not the same. Very often you rely on the returned value from the last statement. The fact that you can't add code at the end without modifying the line that returns stuff is a very good reason to always omit the semicolon after the last statement.

I've been using this style (always a trailing comma after a list, never a trailing semicolon after the last statement in a block) for a few months with great success. There were a few times when it saved me.

Also, whether you use an explicit return or not makes no difference. With or without return, the last block is always special, no matter if you care about the returned value or not. If there is ever a well thought out style guide, I'd expect it to recommend no trailing semicolon.

@zoffixznet
Copy link
Contributor

👍 on removing that sentence. I too found it off-colour when I read it a few days ago. Personally, I leave off the colon deliberately, to indicate the statement's value is used as a return value.

@AlexDaniel
Copy link
Member Author

(Off-topic FWIW) What @zoffixznet just said sounds reasonable too, but I'm convinced that doing that makes this style decision less prominent when someone is reading (or contributing to) your code. I've noticed that in most cases the last line in any block (even if/else) is always somewhat special, so the amount of times I had to add a semicolon to something is probably 0. I can see how it can improve the readability if you have do in front of your if/else, but at the same time I don't see myself removing semicolons if I ever decide to slap a do on something. Strict binary style decisions make it easier for me, but YMMV.

@molecules
Copy link
Contributor

I just improved my pull request (#1479) further. Additional modifications/suggestions are welcome.

zoffixznet pushed a commit that referenced this issue Sep 1, 2017
* Cleaning up "Separating statements by semicolons"

Trying to address #1477

* More explanation, postcircumfix exception

* More concise trailing statement explanation

* removed mention of postcircumfix blocks

Deleting to avoid confusion
@zoffixznet
Copy link
Contributor

Fixed by the PR (merged in 2854b7d )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Documentation issue (primary issue type)
Projects
None yet
Development

No branches or pull requests

5 participants