-
-
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
Format DrumSynth
#7189
Format DrumSynth
#7189
Conversation
someone will want to run through this and check space usage where typecasting is done, and maybe glance through conventions? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some initial thoughts i got from the diff. Try solving these. I haven't included all of it.
You know, it would've taken zero effort to format the entire document if you wanted to satisfy our formatting conventions. |
Unfortunately, I am stupid. |
It is too late now. I have put in non-zero effort which cannot be backspaced. I shall continue to do so. But would be kinda useful if you could tell me more about this |
There are probably other ways, but using VSCode with our |
Ah. The weird stuff I don't understand. I keep forgetting it exists |
Usually, we don't do this because there are a lot of out of scope changes it create when making PRs. But since this is a formatting PR, all the changes in here would be relevant and in scope. |
Wait. All those PRs I plan to do to clean and there's a command I could do that just wasn't being done? |
I notice that some of the block brace work has been deleted, among other things. Your commit would mostly format whitespaces and ordering. |
Let me know if there's anything else that should be done here 👍. |
It looks about right at first glance. I will check it from PC at a later point. Thank you. |
Our |
I notice you have moved the asterisks. I was under the impression that Additionally I perceive some confusing nextline usage/requirement I will probably want to resolve. I will not be at my home computer for about two or three days, so unlikely to do it till then. I will try to see if I can do something about it anyway. I am under the understanding this pull request still be marked as ready for review due to your tendency to keep it that way. |
They actually are the same in this context. This confusion is why we put the pointer with the type instead of with the variable name. |
Feel free to do anything remaining that you think fits with our conventions, I just wanted to help you out a bit since it seemed like you were facing some difficulty with this file. 👍 |
Requesting this to be looked at since am unsure of indentation Additionally view if/else blocks, see if convertable to else-if anywhere
The file seems to be quite clean now. If no one objects or finds any flaws, i'll merge in 2 days. |
This file is so old I am making a separate pull request for it instead of grouping its cleaning with the rest of my categories.
Several issues here.
Bad formatting includes poor space usage (no space around operators / flow control), bad nextline usage and bad indentation (two space indentation instead of tab).
Additionally there is ugly logic (nested if loops).
I will fix as much of the formatting as I can myself. I cannot speak for the rest.
Hopefully the next person approaching this file will have at least a better formatted task ahead of them.