Removing the header boilerplate from the beginning of all source code files#9489
Removing the header boilerplate from the beginning of all source code files#9489ChrisDryden wants to merge 1 commit intouutils:mainfrom
Conversation
|
sorry but i don't see the point of this change?! |
|
Was in the middle of typing out the description, the main discussion about the functional reasons behind the change is in the discussion, but the TLDR is that the text at the beginning seemingly is not required for a functional purpose with relation to the licensing and there are measurable impacts that having additional non-functional text in the source code have on readability and use of LLM's. |
|
Similar to this change: #5184 where the authors header was removed where you said "don't provide any value (the info can be found in the git log)" I believe the same thing applies here since from a practical purpose it doesn't change the licensing of the project by having this there or not and this can be seen in the other various projects that do not include this. My understanding is that this is a relic of how these files used to be more regularly passed around as one offs to include the licensing in the file, but here we only indicate to look at the parent level license anyways. For similar justifications, now that the cargo workspace is able to add the license flag to inherit the parent package licensing infromation, this symlink PR is no longer neccesary: #3131 |
|
I missed the discussion.
|
|
sorry |
|
GNU testsuite comparison: |
|
But why are not symlinks enough? Also are symlinks at same place |
This is a proposal that's based on the discussion topic here: #9464 . From a functional perspective, most MIT licensed projects do not include this header in their source code such as Tokio,
One of the main benefits that this project has compared to the other implementations is the lack of verbosity of the implementations and the readability of the code due to the higher level of abstractions.
Reducing the amount of non-functional boilerplate text in the code has meaningful practical differences when it comes to both the reading of the code and how automated tools such as LLM's are able to summarize and understand the code. When viewing the difference for a human reader it is subjective and harder to get explicit data but when viewing the impacts it has on context window lengths for LLM's there is concrete data showing the direct impact of adding non-functional text input degrading the output of LLM's. https://research.trychroma.com/context-rot has great visualizations to show this impact.
This adds up to around .8% of all of the lines in the project and from a token window perspective it adds up to around 1.2% of all context in the source code.