Re:Why are process gates the hellish spawn of evil you shoul...
by avmich on Wednesday October 19, 2022 @05:24PM
(#33268115)
The first thing I write in a coding guideline, "This is a set of suggestions, not hard and fast rules." So in practice it's harder to figure out if the code is good enough from this standpoint.
What is working, I think, is to have everybody agreed about 1) what actually needs to be done - a good understanding of details of the project - and 2) how it needs to be done - on high level, and on the low level some variations shouldn't matter too much.
Re:Why are process gates the hellish spawn of evil you shoul...
by HeyLaughingBoy on Wednesday October 19, 2022 @05:30PM
(#33268164)
I prefer a coding standards document that is divided up into hard and fast rules and guidelines and clearly states which is which. Otherwise, reviews can quickly degrade into arguments.
Re:Why are process gates the hellish spawn of evil you shoul...
by avmich on Wednesday October 19, 2022 @06:08PM
(#33268483)
Can you give an example of hard and fast rule regarding coding standards? I'd assume people who learned programming by books - and even those who learned otherwise - wouldn't name variables after rock stars, but something not too obvious?
Re:Why are process gates the hellish spawn of evil you shoul...
by HeyLaughingBoy on Wednesday October 19, 2022 @10:04PM
(#33270037)
Sure. In the codebase for an 8-bit embedded system: recursion is forbidden.
Then if they don't you can ding them for not following the process. You can fix problems with process, but all that does is set a minimum floor of quality, it doesn't guarantee anything higher than that.
In your example, I'd have standards for coding practices, and reviews to be sure that they're met, and merges aren't allowed unless the reviewers all approve.