5 ms·

This measures the number of rules in .gitignore files, not language complexity.

by czardoz 10y ago

kqr 10y ago
Elaboration: the number of rules in .gitignore files scale pretty linearly with the number of options you have for tooling. If there are lots of tools that work with your language, your .gitignore template will be big. If there is only one or a few tools, your .gitignore template will be small. Whether or not "language complexity" correlates with "number of options for tooling" is left as an exercise for the reader. Personally, I think there's an argument to be made for popular languages having more tooling options...
deleted 10y ago
[deleted]
ludamad 10y ago
"Build tool complexity" seems less reaching
- ygra 10y ago
  It also probably depends on what development tools people use. If everyone on the project uses a different IDE that's different patterns for each of them, but they all have to be in the ignore file.
  - maze-le 10y ago
    Well, that is what a global gitignore file [1] is all about. Entries specific for your working environment (IDE-files) should be defined in your global gitignore, while everything project-specific (object files, build-directory etc.) should be in the project-gitignore. [1] git config-option: --global core.excludesfile
  - majewsky 10y ago
    Not really. That should be put in ~/.gitignore, e.g. I ignore Vim swap files there so I don't have to do it in every single repo.
deathanatos 10y ago
In Github's .gitignore template, too. For example, most of the entries in the Python one are utterly inane, and won't apply to your project. You can easily trim that file to 1/5 it's size. It includes the ignores for a bunch of directories I've never see any project ever have, two unit test frameworks, two web frameworks, pip's files that are already better covered by virtualenv ignores, four different ways of naming your virtualenvs… This isn't measuring language complexity; this is someone trying to pre-cover any potential case generated by any popular-today third party library.
- danielbarla 10y ago
  The visual studio one seems to cover just about every way you could use VS, and every plugin made for it. This measurement comments more on the neatness of the IDE(s) than any kind of language complexity.
  - paulirwin 10y ago
    Agreed. VS supports dozens of languages across web, desktop, mobile, etc. C#, VB, F#, C, C++, JavaScript, T-SQL, Python... and that's just what I can list off the top of my head. Even with single languages in the list it's not apples-to-apples. "Language complexity" should be removed from the link title.

This measures the number of rules in .gitignore files, not language complexity.

by czardoz 10y ago

This measures the number of rules in .gitignore files, not language complexity.

kqr 10y ago

Elaboration: the number of rules in .gitignore files scale pretty linearly with the number of options you have for tooling. If there are lots of tools that work with your language, your .gitignore template will be big. If there is only one or a few tools, your .gitignore template will be small. Whether or not "language complexity" correlates with "number of options for tooling" is left as an exercise for the reader. Personally, I think there's an argument to be made for popular languages having more tooling options...

deleted 10y ago

[deleted]

ludamad 10y ago

"Build tool complexity" seems less reaching

ygra 10y ago
It also probably depends on what development tools people use. If everyone on the project uses a different IDE that's different patterns for each of them, but they all have to be in the ignore file.
- maze-le 10y ago
  Well, that is what a global gitignore file [1] is all about. Entries specific for your working environment (IDE-files) should be defined in your global gitignore, while everything project-specific (object files, build-directory etc.) should be in the project-gitignore. [1] git config-option: --global core.excludesfile
- majewsky 10y ago
  Not really. That should be put in ~/.gitignore, e.g. I ignore Vim swap files there so I don't have to do it in every single repo.

deathanatos 10y ago

In Github's .gitignore template, too. For example, most of the entries in the Python one are utterly inane, and won't apply to your project. You can easily trim that file to 1/5 it's size. It includes the ignores for a bunch of directories I've never see any project ever have, two unit test frameworks, two web frameworks, pip's files that are already better covered by virtualenv ignores, four different ways of naming your virtualenvs… This isn't measuring language complexity; this is someone trying to pre-cover any potential case generated by any popular-today third party library.

danielbarla 10y ago
The visual studio one seems to cover just about every way you could use VS, and every plugin made for it. This measurement comments more on the neatness of the IDE(s) than any kind of language complexity.
- paulirwin 10y ago
  Agreed. VS supports dozens of languages across web, desktop, mobile, etc. C#, VB, F#, C, C++, JavaScript, T-SQL, Python... and that's just what I can list off the top of my head. Even with single languages in the list it's not apples-to-apples. "Language complexity" should be removed from the link title.