1. 3

    You confuse readibility with style. Style should be consistent but readibility means good abstractions.

    1. 1

      I recently had an encounter with a code base filled with duplicative code, excessive logging, poor abstractions and long methods. Oh, and 50-100 (pretty printed) lines of SQL compressed down to 4 lines of concatenated strings.

      It was typically 2-6 lines of logging, 2 lines for try/catch, 4-6 lines for some braces and then maybe 1-2 lines of logic filled with chained method calls to things that should have been readily accessible. Repeat that for a few hundred lines and you’ve got yourself a “run” method ! Time to move on to the next class.

      There were no primitives to work with. Just masses of code globbed together. It was impossible to read. @_@

    1. 3

      I’m working on some tonality models for this music composition app that’s like an IDE for music. You should sign up here https://docs.google.com/forms/d/1-aQzVbkbGwv2BMQsvuoneOUPgyrc6HRl-DjVwHZxKvo if you wanna be notified when I launch it.

      1. 7

        While there are language-specific tools that help immensely (such as cscope), for me nothing has ever really beaten just knowing find/grep/silversearcher type tooling thoroughly, alongside a couple of shell macros.

        Even monster-sized codebases fit easily in RAM and with a multithreaded grep like silversearcher (ag), navigating to strange and unknown parts takes only a few moments. Combine your newly discovered directories with a few hacky shell macros like in https://gist.github.com/dw/81f9b8cc0d957c41a7b2f6dc85b53358 and you’re all set.

        1. 3

          The rgrep command in Emacs is really nice for that kind of searching.

          1. 1

            check out ripgrep https://github.com/BurntSushi/ripgrep its memetastic

          1. 5

            What a weird argument. Part of writing solid C code is testing it. As far as I know, nobody writes bug free code in any language.

            1. 13

              I gave the author the benefit of the doubt and assumed they were talking about working with tests. I think the point still stands.

              1. 6

                It’s not. Different languages have different classes of bugs. Those in C/C++ tend to have disastrous consequences.

                1. 9

                  Such statements would be less hyperbolic if people recognized that only a small subset of C bugs belong in that class of potentially-disasterous and exclusive to C, and that only a small subset of such bugs make it through code review and testing, and that a small subset of these bugs are actually exploitable in the real world.

                  Bugs in C programs get publicized really often because there’s a crapton of such code out there in active use. But that kind of publicity doesn’t give people any sense of scale, and the issue is blown completely out of proportion. If that weren’t enough, the discussion will derail into UB and people assume a deliberately adversial compiler that literally tries to turn every instance of UB into an exploitable bug. It almost sounds as if the standard somewhere said that compilers are not permitted to let the code behave in any reasonable manner in the face of UB…

                  1. 17

                    if people recognized that only a small subset of C bugs

                    That mostly don’t exist when using a type-safe, memory-safe language in most of your code. It’s impossible to write idiomatic code in them with the same errors resulting in something more than an exception. Most hackers aiming for code injection in such languages try to hit the runtimes or libraries that are written in C or C++. Says a lot.

                    Meanwhile, there were operating systems written in SPARK Ada, Modula-3, Java, and Rust whose unsafe portions were kept to a much lower percentage with rest immune to entire classes of vulnerabilities. Microsoft’s VerveOS made those parts safe with proven assembly the rest of the OS (in C#) interfaced to. I bring these up to preempt the common counter of the lower parts having to be written in C/C++ because they’re the only thing that can handle low-level stuff. I get that false claim a lot in these discussions.

                    1. 4

                      Just as a simple example, the very common failures to properly parse input strings and firewall them from e.g. SQL databases are language independent.

                      1. 7

                        We’re talking about whether using a different language improves security by removing an entire class of bugs. The status quo Im countering are C and C++ bugs leading to code injection that controls the machine. You side-step that evidencw to counter that people building web or database apps can have an extra problem.

                        So what. That average programmers are producing things immune to many forms of code injection by default is already better than C/C++ situation where even veterans get hit by those bugs periodically. And if you’re concerned about SQL injection, there’s similarly methods to immunize against it in apps. Ur/Web, Opa, and Spectre are examples of languages or platforms foing stuff like that.

                        So, the empirical evidence shows these other languages and preventative methods knock out lots of peoblems. That’s a net gain as secure coding is rare skill. From there, there’s still stuff to watch for.

                    2. 1

                      a small subset of C bugs belong in that class of potentially-disasterous and exclusive to C

                      Could you elaborate on this class? What are the typical disastrous gotchas exclusive to C? Is there a list on a paper or somewhere?

                      1. 4

                        Buffer overflow (including those induced by C’s strange string semantics) and use-after-free are the big common ones; also integer overflow can immediately be a security bug in C. Switch fall-through is not quite unique to C but close. I’m sure there are more that we’d notice if we fixed those.

                    3. 1

                      That argument would require some specifics and data - not the “I can’t write C/C++ without testing” presented in the article.

                  1. 4

                    btw i think that there should be a machine learning tag because I think that ML definitely belongs here but there’s no tag.