4 ms·
This is what I came here for. There's an obvious comprehensibility complexity to code to anyone who has spent almost any time what so ever trying to make somet
by Verdex 3y ago
This is what I came here for.
There's an obvious comprehensibility complexity to code to anyone who has spent almost any time what so ever trying to make something happen in software. However, we've got zero academics or theory around it.
Just 'best practices' (ie a thing other people are known to do so if things go wrong we can deflect blame).
And code smells (ie the code makes your tummy feel bad. yay objective measures).
And dogma (ie "only ONE return point per function" or "TDD or criminal neglect charges").
Sure, please do something for QA because it'll be better than nothing. But we're probably a few decades of waiting for actual theoretical underpinnings that will actually allow us to make objective tradeoffs and measurements.
- readthenotes1 3y agoYou forgot the dogma of only one entry point per function, back from the day when you could do both. (One exit point is a pet peeve of mine since it often makes the code a lot harder to read and think about vs exit asap)
- randomdata 3y agoYou may still not buy into it, but note that single exit was established for languages like C where an early exit can make it difficult to ensure that all resources are freed. It isn't meant for every language – and, indeed, languages that are not bound by such constraints usually promote multiple exit because of the reasons you bring up.
- Spivak 3y agoAnd even that is wrong, single entrance/exit was originally because you had subroutines designed to be goto'd into at different points for different behavior and would goto different points outside the subroutine as the exit. There are pretty much no languages left today where it's even possible to violate this principle without really trying, it's not about having single a return it's about all the functions starting at the top and return statements always taking you back to the same place in the code.
- pjmlp 3y agoThere is plenty of academics on it, as real engineers, those that studied Software Engineering or Informatics Engineering, instead of fake engineering titles from bootcamps, should be aware. Usually available as optional lectures during the degree, or later as Msc and PhD subjects.
- lainga 3y agoSure, I've run into a couple. Here's a chart of Defects per KLOC. Great.
- Verdex 3y agoI'm all ears. Although, so far I've only bumped into cyclomatic complexity (with some studies showing that it has worse predicting power than lines of code) and lines of code.
- pjmlp 3y agoHere is one, https://swc.rwth-aachen.de/teaching/courses/2022-summer-semester/software-quality-assurance/ https://swc.rwth-aachen.de/teaching/courses/2022-summer-seme...
- Verdex 3y agoI don't know. I was hoping for something like: "We know inheritance is bad because when we convert the typical example over to this special graph it forms a non-compact metric space" Or something like that. Even though I find cyclomatic complexity uncompelling, it at the very least can slurp up code and return a value. Nicely objective, just not particularly useful or insightful to whether or not things are easy to understand. The provided link looks suspiciously like they're going to talk about the difference between system, integration, and unit tests. The importance of bug trackers. And linters / theorem provers maybe. I don't think these are bad things, but it's kind of a statistical approach to software quality. The software is bad because the bug chart looks bad. Okay, maybe, but maybe you just have really inexperienced people working on the project. Technically, the business doesn't need to know the difference, but I would like to.
- RandyRanderson 3y agoI wish more ppl felt this way. What a compliment it is to oneself when I hear ppl saying "write clean code" as if they know its address and had dinner with clean code just last night. I was thinking there should be some metric around d(code)/dt . That is, as the software is used, 'bad' code will tend to change a lot but add no functionality. 'Good' code will change little even when it's used mode.
- AlotOfReading 3y agod(code)/dt isn't a very good metric though. Think of the Linux kernel. Drivers get some of the least maintenance work and are broadly the lowest quality part of the kernel. arch/ is busier than drivers/, but anything you find in the parts being touched are also significantly higher quality.
- satisfice 3y agoThe scientific groundwork for excellent testing, anyway, has already been done-- but not in the realm of computer science. This is because computer scientists are singularly ill equipped to study what computer scientists do. In other words, if you want to understand testing, you have to watch testers at work, and that is social science research. CS does not take social science seriously. An example of such research done well can be found in Exploring Science, by Klahr. The author and his colleagues look very closely at how people interact with a system and experiment with it, leading to wonderful insights about testing processes. I've incorporated those lessons into my classes on software testing, for instance.
- aschearer 3y agoI found these thought provoking: The Power of 10: Rules for Developing Safety-Critical Code[1] Assessing the Relationship between Software Assertions and Code Quality: An Empirical Investigation[2] Cyclomatic Complexity and Basis Path Testing Study[3] [1]: https://web.eecs.umich.edu/~imarkov/10rules.pdf https://web.eecs.umich.edu/~imarkov/10rules.pdf [2]: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2006-54.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... [3]: https://ntrs.nasa.gov/api/citations/20205011566/downloads/20205011566.pdf https://ntrs.nasa.gov/api/citations/20205011566/downloads/20...