Comment on When you look at some random project's source code for the first time how do you assess time, quality, and complexity at first glance?

onlinepersona@programming.dev ⁨11⁩ ⁨months⁩ ago

TL;DR I look at the package first, before opening it. Unfortunately, often the packaging says a lot about the project

  1. A proper README
  2. A section in the README about how to setup a dev environment - without that it’s often just a guessing game I don’t have time for
  3. A section in the README about how to deploy or run the project
  4. Test cases that actually mean something, not just boilerplate assert true
  5. Some kind of CI setup with steps for code quality (lint, format, type checking, …)
  6. Documentation generation
  7. Pull/merge requests / external project activity

Some programming languages still have either no tooling or communities that shun it. C, C++ and PHP come to mind. Many projects from those languages are written by old folk, people who only use editors (vim, emacs, nano, …) that don’t come with tooling out of the box, or assume a might amount of things about dev machines. They are languages and communities I shun.

Go, Python, Rust, Typescript, and other languages are chock-full of developer tooling with people using IDEs or at least editors with extensions/plugins for improved developer lives. Especially Rust and Typescript are often setup with a bunch of tooling that has to be actively ignored by the developer. Often it’s much easier to get started, run the project, run tests, read the code, load it into an IDE or editor with advanced language support (goto definition, refactoring, integrations for running and testing code, …).

CC BY-NC-SA 4.0

source
Sort:hotnewtop