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

Style Guide for Haskell #152

Closed
lulucca12 opened this issue Jun 28, 2018 · 14 comments
Closed

Style Guide for Haskell #152

lulucca12 opened this issue Jun 28, 2018 · 14 comments
Assignees
Labels
Discussion This is open for a discussion.

Comments

@lulucca12
Copy link
Contributor

Style Guide for Haskell
There are some style considerations to make in regret to writing Haskell code.

Paradigm Preference
Normally Haskell programmers prefer to write declarative code instead of imperative code, but as imperative code is used on the mainstream and most non-haskell coders are more familiar with it, it could be viewed as an alternative.

Code Readability
As said in the "how_to_contribute.md" file we should use the style preferences of the language we are writing, but we should also consider readability as a must, because our code is going to be public and accessible on the internet.
I would recommend writing code as readable as possible even if you would rewrite it in a not so familiar style of coding.

An example:

euclidSub :: Integer -> Integer -> Integer
euclidSub a b = inner (abs a) (abs b) where
  inner a b =
    if a == b then
      a
    else if a < b then
      euclidSub a (b - a)
    else
      euclidSub (a - b) b

Could Be wiritten as:

euclidSub :: Integer -> Integer -> Integer
euclidSub a b = inner (abs a) (abs b)
  where
    inner a b
      | a == b = a
      | a < b = euclidSub a (b - a)
      | otherwise = euclidSub (a - b) b

(Example currently in use in the Euclidean Algorithm)

@june128 june128 added the Discussion This is open for a discussion. label Jun 28, 2018
@leios
Copy link
Member

leios commented Jun 28, 2018

As far as haskell code is concerned, most of the code has been written by @jiegillet . To be honest, we were lacking haskell proficiency, so we may have not been reviewing the language as effectively as we could. This is a good discussion to have, thanks for bringing it up!

@june128
Copy link
Member

june128 commented Jun 28, 2018

I think it should be in the style most Haskell programmers are used to, that would make the most sense for me. But let's get a discussion going, since I'm no Haskell expert by any means :)

@lulucca12
Copy link
Contributor Author

lulucca12 commented Jun 28, 2018

I think we should try using this resources as a base Ganeti code style guidlines for open source coding and University of Pennsylvania coding styles but cosider replacing the Haddock and documentation comments with text between code blocks, because we are already writing documentation, and using "hlint" before submitting code.

@lulucca12
Copy link
Contributor Author

We could use also "brittany", "hindent" or "stylish-haskell" before submitting code

@jiegillet
Copy link
Member

Hi @lulucca12, thanks for your input. I'm the main Haskell contributor for the Algorithm Archive, and I'm pretty sloppy when it comes to following style guides, so I'll be happy to discuss. The example you picked was one of the few not written by me though, I would have written it like you did, I think. Would you mind taking a look at one of my contributions and tell me what you think?

@lulucca12
Copy link
Contributor Author

lulucca12 commented Jun 29, 2018

Hello @jiegillet I've seen your code style and I thought it was pretty good! There are some observations to make, thought: You normally state the types of your functions whats really good, but you should be clear of the type of Main too! Specially if you are trying to do some more advanced IO stuff. Your code style is very imperative like, this is great but it make code really big, so you could try using more composition and point-free styles to shorten it up, like in your code:

putStrLn $ "Length: " ++ (show $ length encoded) 

that, as hlint suggested could be shortened to:

putStrLn $ "Length: " ++ show (length encoded) 

to avoid $ and be in a more familiar way of coding.
Besides that, this are the only considerations I have to make.

@jiegillet
Copy link
Member

For some reason, I never state the type of main since I always keep it IO (). Easy fix, though. My code style is imperative? Haha that does hurt, because I love point free style ^^ I guess I have a lot more to learn. I'll try using hlint and learn from it. Thank you for your review!

@lulucca12
Copy link
Contributor Author

Thank you for participating with the portability of the code to Haskell, and the application of new algorithms 😄

@jiegillet
Copy link
Member

It's my pleasure, I love Haskell. I've been teaching it in the last few months too ^^

@jiegillet
Copy link
Member

@lulucca12, would you like to submit a PR with your changes to the Euclidian Algorithm? I can also do it if you prefer.
Also, would you be interested in a code review? I've just submitted #193 and it's usually hard for us to find people to review Haskell. No pressure obviously :)

@lulucca12
Copy link
Contributor Author

lulucca12 commented Jul 8, 2018

@leios @julianschacher @jiegillet I am restarting the activity in this issue to note what we should do about the use of Style Guides and linting programs as a recommendation to make the code clear and
to ask if we need to open a new issue that is more generic about how we should make clear to new contributors (in the guidelines or somewhere else) the good habits of styling, linting and, maybe, code testing in all programming languages before submitting them (to ensure code consistency), not just in Haskell.

@leios
Copy link
Member

leios commented Jul 8, 2018

@lulucca12 Yeah. This is a good idea. We didn't really know where to put this information or what information would be needed for every language, so it was kinda left dangling for a bit. Any suggestions?

EDIT: You guys have done a great job with haskell, so we could use it as a test language, and then update all other languages to follow suit

@jiegillet
Copy link
Member

We could put it in the Wiki.
There would be a general section (always have a main, maximum 80 characters wide, have consistent style, have explicit commit messages...) and subsections for different languages with links to style guides, prettifiers and whatever is good for that language.

@lulucca12
Copy link
Contributor Author

Yes, I think this is great! I'll close this issue and open another one that focuses on the page itself in the wiki, not in the specific Haskell style.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion This is open for a discussion.
Projects
None yet
Development

No branches or pull requests

4 participants