5 ms·

>worry not, by adding std::cmake to the standard library and you’ll see how it’s absolutely a game changer I'm pretty sure my stomach did somersaults on that.

>worry not, by adding std::cmake to the standard library and you’ll see how it’s absolutely a game changer I'm pretty sure my stomach did somersaults on that. But as for the advice: >Get out the chainsaw and rip out everything that’s not absolutely required to provide the features your company/open source project is advertising and selling I hear you, but this is incredibly dangerous. Might as well take that chainsaw to yourself if you want to try this. It's dangerous for multiple reasons. Mainly it's a case of Chesterton's fence. Unless you fully understand why X was in the software and fully understand how the current version of the software is used, you cannot remove it. A worst case scenario would be that maybe a month or so later you make a release and the users find out an important feature is subtly broken. You'll spend days trying to track down exactly how it broke. >Make the project enter the 21st century by adding CI, linters, fuzzing, auto-formatting, etc It's a nice idea, but it's hard to do. One person is using VIM, another is using emacs, another is using QTCreator, another primarily edits in VSCode.. Trying to get everyone on the same page about all this is very, very hard. If it's an optional step that requires that they install something new (like commit hook) it's just not going to happen. Linters also won't do you any good when you open the project and 2000+ warnings appear.

aaronbrethorst 3y ago
An optional step locally like pre-commit hooks should be backed up by a required step in the CI. In other words: the ability to run tests locally, lint, fuzz, format, verify Yaml format, check for missing EOF new lines, etc, should exist to help a developer prevent a CI failure before they push. As far as linters causing thousands of warnings to appear on opening the project, the developer adding the linter should make sure that the linter returns no warnings before they merge that change. This can be accomplished by disabling the linter for some warnings, some files, making some fixes, or some combination of the above.
zer00eyz 3y ago
>> It's a nice idea, but it's hard to do. One person is using VIM, another is using emacs, another is using QTCreator, another primarily edits in VSCode.. Trying to get everyone on the same page about all this is very, very hard. This is what's wrong with our industry, and it's no longer an acceptable answer. We're supposed to be fucking professional, and if a job needs to build a tool chain from the IDE up we need to learn to use it and live with it. Built on my machine, with my IDE, the way I like it and it works is not software. It's arts and fucking crafts.
- cratermoon 3y ago
  If you're saying everyone should agree on the same IDE and personal development toolset, I disagree, sort of. The GP was suggesting the effort to add CI, linters, fuzzing, auto-formatting, etc was too hard. If that can be abandoned entirely, perhaps the legacy codebase isn't providing enough value, and the effort to maintain it would be better spent replacing it. But the implication is that the value outweighs the costs. Put all the linters, fuzzing, and format checking in an automated build toolchain. Allow individuals to work how they want, except they can't break the build. Usually this will reign in the edge cases using inadequate tools. The "built on my machine, with my IDE, the way I like it and it works" is no longer the arbiter of correct, but neither does the organization have to deal with the endless yak shaving over brace style and tool choice.
  - eropple 3y ago
    > neither does the organization have to deal with the endless yak shaving over brace style and tool choice I hear you, but an organization that fears this, instead of Just Pick Something And Deal With It, is an organization that probably doesn't have the right people in it to succeed at any task more arduous than that.
    - cratermoon 3y ago
      Conversely, and organization that imposes arbitrary choices and isn't capable of allowing people do use the tools they know best probably doesn't attract the best people. There are many different kinds of hammers, and making everyone who uses hammers use the same kind is, to say the least, counter productive.
      - eropple 3y ago
        I get where you're coming from, but frankly: nah. If you are so in-the-rut that you can't switch, say, text editors or IDEs and are compelled to have an Incredibly Normal Day about it, you're probably not actually possessed of the plasticity to be somebody I want to work with. I use vim, IntelliJ, Visual Studio, and VSCode at least once every two weeks apiece, and it's no skin off my back to switch. Do thou likewise.
electroly 3y ago
> It's a nice idea, but it's hard to do. One person is using VIM... The things the author listed there are commonly not IDE integrated. I've never seen a C++ development environment where cpplint/clang-tidy and fuzzers are IDE integrated, they're too slow to run automatically on keystrokes. Auto-formatting is the only one that is sometimes integrated. All of this stuff you can do from the command line without caring about each user's chosen development environment. You should definitely at least try rather than giving up before you start just because you have two different text editors in use. This is C++; if your team won't install any tools, you're gonna have a bad time. Consider containerizing the tools so it's easier.
- gpderetta 3y ago
  Clangd will happily run clang-tidy as part of completion/compile-as-you-type/refactor/auto independent. On the editor/IDE of your choose. I wouldn't call it fast, but it is quite usable.
- throwaway2037 3y ago
  > I've never seen a C++ development environment where cpplint/clang-tidy and fuzzers are IDE integrated CLion from JetBrains has clang-tidy integrated (real-time).
  - planede 3y ago
    I assume it's clangd? It can be used from vim, vscode, ... etc as well and get a uniform IDE diagnostic experience across text editors.
- chlorion 3y ago
  In Emacs I have clangd and clang-tidy running on each key stroke! The project size is probably a lot smaller than what most people are working on though, and I have a fast CPU and NVME disk, but it's definitely possible to do! I'm not sure about the fuzzer part though.
IshKebab 3y ago
> One person is using VIM, ... I don't get your point. You know you can autoformat outside editors right? Just configure pre-commit and run it in CI. It's trivial. > If it's an optional step that requires that they install something new (like commit hook) it's just not going to happen. It will because if they don't then their PRs will fail CI. This is really basic stuff, but knowledge of how to do CI and infra right does seem to vary massively.
selfmodruntime 3y ago
> It's a nice idea, but it's hard to do. One person is using VIM, another is using emacs, another is using QTCreator, another primarily edits in VSCode.. Trying to get everyone on the same page about all this is very, very hard. I must have missed the memo where I could just say no to basic things my boss requires of me. You know, the guy that pays my salary.
- saagarjha 3y ago
  As others have mentioned, none of these things actually change your development workflow. But if they did, you do have the ability to say no. If your boss fails to understand that you have an environment that you're productive in, that sounds like a bad place to work.
  - flykespice 3y ago
    Every company have their own workflow adapted to their tooling so that teams can work among themselves frictionless. It's ok if you use your own tooling you are comfortable with, but you should adapt to their workflow, and the employer has no obligation to tweak their workflow to integrate your own, it's yours to adapt.
  - danlugo92 3y ago
    yikes
- rcxdude 3y ago
  You can, in fact, just do that. You are allowed. You may get fired if you are too much of a headache, but employers are actually flexible.
Kamq 3y ago
> It's a nice idea, but it's hard to do. One person is using VIM, another is using emacs, another is using QTCreator, another primarily edits in VSCode.. Trying to get everyone on the same page about all this is very, very hard. Bullshit, all of these (and additionally C lion) are fairly easy to configure these for, with the possible exception of QTCreator (not a ton of experience on my end). Just make it a CI requirement, and let everyone figure it out for their own tools. If you can't figure that out, you get to run it as a shell script before you do your PRs. If you can't figure that out, you probably shouldn't be on a legacy C++ project.
theamk 3y ago
> It's dangerous for multiple reasons. Mainly it's a case of Chesterton's fence. Unless you fully understand why X was in the software... If this is a function that no one links to, and your project does not mess with manual dynamic linking (or the function is not exposed), then it's pretty safe to remove it. If it's internal utility which does not get packaged into final release package, it is likely be safe to remove too. If it's a program which does not compile because it requires Solaris STREAMS and your targets are Linux + MacOS - kill it with fire. (Of course removing function calls, or removing functionality that in-use code depends on, is dangerous. But there is plenty of stuff which has no connection to main code)

aaronbrethorst 3y ago

An optional step locally like pre-commit hooks should be backed up by a required step in the CI. In other words: the ability to run tests locally, lint, fuzz, format, verify Yaml format, check for missing EOF new lines, etc, should exist to help a developer prevent a CI failure before they push. As far as linters causing thousands of warnings to appear on opening the project, the developer adding the linter should make sure that the linter returns no warnings before they merge that change. This can be accomplished by disabling the linter for some warnings, some files, making some fixes, or some combination of the above.

zer00eyz 3y ago

>> It's a nice idea, but it's hard to do. One person is using VIM, another is using emacs, another is using QTCreator, another primarily edits in VSCode.. Trying to get everyone on the same page about all this is very, very hard. This is what's wrong with our industry, and it's no longer an acceptable answer. We're supposed to be fucking professional, and if a job needs to build a tool chain from the IDE up we need to learn to use it and live with it. Built on my machine, with my IDE, the way I like it and it works is not software. It's arts and fucking crafts.

cratermoon 3y ago
If you're saying everyone should agree on the same IDE and personal development toolset, I disagree, sort of. The GP was suggesting the effort to add CI, linters, fuzzing, auto-formatting, etc was too hard. If that can be abandoned entirely, perhaps the legacy codebase isn't providing enough value, and the effort to maintain it would be better spent replacing it. But the implication is that the value outweighs the costs. Put all the linters, fuzzing, and format checking in an automated build toolchain. Allow individuals to work how they want, except they can't break the build. Usually this will reign in the edge cases using inadequate tools. The "built on my machine, with my IDE, the way I like it and it works" is no longer the arbiter of correct, but neither does the organization have to deal with the endless yak shaving over brace style and tool choice.
- eropple 3y ago
  > neither does the organization have to deal with the endless yak shaving over brace style and tool choice I hear you, but an organization that fears this, instead of Just Pick Something And Deal With It, is an organization that probably doesn't have the right people in it to succeed at any task more arduous than that.
  - cratermoon 3y ago
    Conversely, and organization that imposes arbitrary choices and isn't capable of allowing people do use the tools they know best probably doesn't attract the best people. There are many different kinds of hammers, and making everyone who uses hammers use the same kind is, to say the least, counter productive.
    - eropple 3y ago
      I get where you're coming from, but frankly: nah. If you are so in-the-rut that you can't switch, say, text editors or IDEs and are compelled to have an Incredibly Normal Day about it, you're probably not actually possessed of the plasticity to be somebody I want to work with. I use vim, IntelliJ, Visual Studio, and VSCode at least once every two weeks apiece, and it's no skin off my back to switch. Do thou likewise.

electroly 3y ago

> It's a nice idea, but it's hard to do. One person is using VIM... The things the author listed there are commonly not IDE integrated. I've never seen a C++ development environment where cpplint/clang-tidy and fuzzers are IDE integrated, they're too slow to run automatically on keystrokes. Auto-formatting is the only one that is sometimes integrated. All of this stuff you can do from the command line without caring about each user's chosen development environment. You should definitely at least try rather than giving up before you start just because you have two different text editors in use. This is C++; if your team won't install any tools, you're gonna have a bad time. Consider containerizing the tools so it's easier.

gpderetta 3y ago
Clangd will happily run clang-tidy as part of completion/compile-as-you-type/refactor/auto independent. On the editor/IDE of your choose. I wouldn't call it fast, but it is quite usable.
throwaway2037 3y ago
> I've never seen a C++ development environment where cpplint/clang-tidy and fuzzers are IDE integrated CLion from JetBrains has clang-tidy integrated (real-time).
- planede 3y ago
  I assume it's clangd? It can be used from vim, vscode, ... etc as well and get a uniform IDE diagnostic experience across text editors.
chlorion 3y ago
In Emacs I have clangd and clang-tidy running on each key stroke! The project size is probably a lot smaller than what most people are working on though, and I have a fast CPU and NVME disk, but it's definitely possible to do! I'm not sure about the fuzzer part though.

IshKebab 3y ago

> One person is using VIM, ... I don't get your point. You know you can autoformat outside editors right? Just configure pre-commit and run it in CI. It's trivial. > If it's an optional step that requires that they install something new (like commit hook) it's just not going to happen. It will because if they don't then their PRs will fail CI. This is really basic stuff, but knowledge of how to do CI and infra right does seem to vary massively.

selfmodruntime 3y ago

> It's a nice idea, but it's hard to do. One person is using VIM, another is using emacs, another is using QTCreator, another primarily edits in VSCode.. Trying to get everyone on the same page about all this is very, very hard. I must have missed the memo where I could just say no to basic things my boss requires of me. You know, the guy that pays my salary.

saagarjha 3y ago
As others have mentioned, none of these things actually change your development workflow. But if they did, you do have the ability to say no. If your boss fails to understand that you have an environment that you're productive in, that sounds like a bad place to work.
- flykespice 3y ago
  Every company have their own workflow adapted to their tooling so that teams can work among themselves frictionless. It's ok if you use your own tooling you are comfortable with, but you should adapt to their workflow, and the employer has no obligation to tweak their workflow to integrate your own, it's yours to adapt.
- danlugo92 3y ago
  yikes
rcxdude 3y ago
You can, in fact, just do that. You are allowed. You may get fired if you are too much of a headache, but employers are actually flexible.

Kamq 3y ago

> It's a nice idea, but it's hard to do. One person is using VIM, another is using emacs, another is using QTCreator, another primarily edits in VSCode.. Trying to get everyone on the same page about all this is very, very hard. Bullshit, all of these (and additionally C lion) are fairly easy to configure these for, with the possible exception of QTCreator (not a ton of experience on my end). Just make it a CI requirement, and let everyone figure it out for their own tools. If you can't figure that out, you get to run it as a shell script before you do your PRs. If you can't figure that out, you probably shouldn't be on a legacy C++ project.

theamk 3y ago

> It's dangerous for multiple reasons. Mainly it's a case of Chesterton's fence. Unless you fully understand why X was in the software... If this is a function that no one links to, and your project does not mess with manual dynamic linking (or the function is not exposed), then it's pretty safe to remove it. If it's internal utility which does not get packaged into final release package, it is likely be safe to remove too. If it's a program which does not compile because it requires Solaris STREAMS and your targets are Linux + MacOS - kill it with fire. (Of course removing function calls, or removing functionality that in-use code depends on, is dangerous. But there is plenty of stuff which has no connection to main code)