-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Improve internal documentation #858
Comments
I am currently walking through the code and making notes on what each function does or is used for. I started doing this so I can start contributing to the project in a meaningful manner, but I could put together a pull request when I'm done. I just want to know if there is any comment style you prefer or if there is a library you admire for its documentation? Also, would you be opposed to having a .stylish-haskell.yaml for stylish-haskell? The reason is that |
First code question, at the end of Main.hs:
why do you replace these characters in the JWT secret when |
@Skyfold thanks for volunteering to help with this! Good comments will make a big difference for everyone. I'll review your questions in more detail tonight and will respond then. |
For comment style, adding one for each function is good, like {-|
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
commodo consequat.
-}
lorem :: Ipsum -> Dolor
lorem ... Example code for a whole module is also nice when it can show how parts fit together. Stuff like: module Foo.Bar.Baz
(
-- * Example usage
-- $use
-- * A section
Thingie(..)
-- * More stuff
, fun
, joy
) where
-- now at the bottom of the file:
-- $use
--
-- Here's how to do some stuff
--
-- > this is a raw haskell code block
-- >
-- > more code goes here
--
-- Then another example
--
-- > more fun in this code block
-- > ... If there is anything noteworthy about individual fields of a data constructor you can document them individually as well like we do for Of course the haskell wiki page about comments makes a good point that it's better to fix surprising behavior than to comment it, so keep an eye out for weird things in the code that maybe ought to be fixed too. For the base64 question, JWT uses base64 with a "URL and Filename Safe Alphabet" aka base64url so we must translate it to regular base64 before decoding. Also I never heard of |
Thanks for the detailed reply. Do you want to have a header for each file, example? I am not entirely sure what is happening in the |
Yeah the mingw32_HOST_OS is for conditional compilation. Signal stuff won't compile on windows because AFAICT windows doesn't have signals. For sigTERM we release the pool because sometimes the connections weren't properly closed (see #268). For sigHUP actually I'm not sure that releasing the pool is required...that's interesting. I guess it hasn't hurt and presumably sigHUP is a manual event that doesn't happen very often. |
Some time ago I tried to integrate https://github.com/sol/doctest on some of the functions. It seemed really useful as it could serve as both documentation and unit tests. This would greatly improve clarity in the more complicated modules such as QueryBuilder and DbRequestBuilder. However at that time, Maybe the situation has improved and we could give |
Haddock warns about many top level functions and types that lack documentation. Some of these functions speak for themselves, but others would benefit from comments explaining their motivation and context.
The text was updated successfully, but these errors were encountered: