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

Should we avoid using non-ascii, i.e. utf-8 characters in our coding style? #18

Closed
TeroFrondelius opened this issue Jun 7, 2015 · 7 comments

Comments

@TeroFrondelius
Copy link
Member

@ahojukka5 issues are easy to close. I think it's better to have one topic per issue, it's easier to keep track of them.

Anyway this discussion was started in #3 and this relates also to #5.

I don't have a clear opinion. Both ways have their advantages. For human readability full letter set is better, it makes the reading of the code comparable to the scientific paper, then again avoiding strange characters would probably make debugging much easier.

@ahojukka5
Copy link
Member

http://julia.readthedocs.org/en/latest/manual/unicode-input/

There's a self-explaining table how to use utf8 characters and I think in future we will see a lot of these. Of course we could see a lot of difficulties when debugging, 𝘩 != h (U+1D629 != "h"), if we take advantage of full unicode character table. Firefox is not even correctly showing all the characters (today). Notebook rendering engine seems to be broken and drawing red rectangles for every non-ascii character. And this Coverage.jl.

In the other hand, when using e.g. creek symbols like α, β, γ, there's no risk of confusion. At least when not using 𝛂, 𝛃, or 𝛄. While they have a clear mathematical sense they are hard to type without good support of editor / notebook, meaning that user has to copy-paste variables from some sort of unicode table.

Maybe we should consider something like we don't use them in actual code but in notebooks they can be used for clarity?

@ovainola
Copy link
Contributor

ovainola commented Jun 8, 2015

@ahojukka5 I think that is the safest option to do. Althought it diminishes readablity in the code, reliability increases. At least with some editors code seems to break down if there's added greek symbols since they can't render them.

Offtopic: I added one greek symbol in the shape_functions.jl to test coverage.jl. This time it didn't break down but scipped the file containing greek symbol. I don't know did it do it because there were no tests available for that for file or because it had that symbol...

@TeroFrondelius
Copy link
Member Author

Let's vote to close this issue. I vote NO to non-ascii. @ahojukka5 and @ovainola your votes please?

Whoever will close this, please remember to add this information to the https://github.com/ovainola/JuliaFEM/blob/master/CONTRIBUTING.md

@ahojukka5
Copy link
Member

NO, we should not use them in actual program code.

@ovainola
Copy link
Contributor

I say NO to non-ascii code.

@ahojukka5
Copy link
Member

No utf-8 characters to program code. Updated contributing.md.

@TeroFrondelius
Copy link
Member Author

Here is the test I added to keep control. c752ea1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants