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?

Submitted ⁨⁨8⁩ ⁨months⁩ ago⁩ by ⁨j4k3@lemmy.world⁩ to ⁨programming@programming.dev⁩

I’m just generalizing, like if you want to copy some cleaver feature or modify some Python program you came across, what are the red or green flags indicating how well your (or particularly some hobbyist’s/your early learning self’s) results are likely to turn out?

Also how can you tell when reading into such a project is going to be a major project that is beyond the scope of you ultimate goals. For instance, I wanted to modify Merlin 3d printer firmware for hardware that was not already present in the project, but as an Arduino copy pasta hobbyist, despite my best efforts, that was simply too much for me to tackle at the time because of the complexity of the code base and my limited skills.

How do you learn to spot these situations before diving down the rabbit hole? Or, to put it another way, what advice would you give yourself at this stage of the learning curve?

source

Comments

Sort:hotnew top

onlinepersona@programming.dev ⁨8⁩ ⁨months⁩ ago
TL;DR I look at the package first, before opening it. Unfortunately, often the packaging says a lot about the project

A proper README

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

A section in the README about how to deploy or run the project

Test cases that actually mean something, not just boilerplate assert true

Some kind of CI setup with steps for code quality (lint, format, type checking, …)

Documentation generation

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
- MonkderZweite@feddit.ch ⁨8⁩ ⁨months⁩ ago
  
  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
  
  Software brittleness
  
  Preferable to not require a special setup.
  
  source
  - Lucky@programming.dev ⁨8⁩ ⁨months⁩ ago
    Even if you don’t have a special setup, having a section telling you that is still a helpful thing to quickly assess a new project.
    
    I appreciate knowing that a project should Just Work with minimal setup so I don’t have to guess or make assumptions
    
    source
SorteKanin@feddit.dk ⁨8⁩ ⁨months⁩ ago

How do you learn to spot these situations before diving down the rabbit hole? Or, to put it another way, what advice would you give yourself at this stage of the learning curve?

Think of the absolute simplest thing you could do that is somewhat related to your actual goal. Now do something even simpler than that. Should be easy right?

This often happens for aspiring game devs. Everyone is like “I wanna make the next <insert AAA game that had 20 million dollar budget>”. But start by making Pong. Should be simple right?

source
jeffhykin@lemm.ee ⁨8⁩ ⁨months⁩ ago
Use cloc to get an idea of line count.

See how hard it is to find the entry point

Try building it

Try hacking a feature into it

Try hacking a bigger feature

Thing is, for repos of any typical size, its going to take a lot more than a glance to know.

For example the Atom Editor codebase is immaculate, best formatting/commenting I’ve ever seen. But getting it to build is a nightmare, so its too hard to contribute to/hack.
source