Replies: 2 comments
-
The entire point of |
Beta Was this translation helpful? Give feedback.
0 replies
-
Unsure how best to refer to the conversation that took place apart from sharing the first message's link: https://discord.com/channels/592103645835821068/592106336838352923/1393553824546951222 Regardless, the TLDR is the plan for Lilly will be to revert the formatting style to whatever |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
This project has apparently evolved its own unique style/format for how V code should be written to match a certain set of visual characteristics. If we were to run the standard "v fmt" utility against the Lilly code base we can see that many "standard" opinions of formatting V code now heavily deviates from the unique style we have cultivated in this project.
I am considering at some point with this in mind to implement (either by modifying the existing v fmt utility or a from scratch solution) our own "Lilly specific" code style formatter that can be automatically applied as one of the
make.vsh
script tasks. This would ensure that any contributions made can be guaranteed to be consistent with the existing stylistic characteristics of the code base, without @tauraamui having to manually ensure this on any 3rd party contributions or even contributions from him either.This feels like a medium to large undertaking, so until it becomes demonstrably necessary (ie., the overhead of enforcing style consistency on PRs outweighs the effort to make such a tool), this is going to remain just an idea, or potentially a low priority issue in the backlog. However, what do others think? I'm opening this for discussion to log this idea, but also to have others take on this.
Beta Was this translation helpful? Give feedback.
All reactions