problems with large code bases

[flint matrix]

in larger code bases where you have hundreds of classes, is it more common to create duplicate classes because you don't think a class exists or don't remember a class. usually a more senior member of the team and someone who's really familiar with the codebase can point this out, but there's a point where the codebase is really large that i don't expect anyone to know exactly where everything is

[rain pebble]

<@&987246399047479336> please have a look, thanks.

[acoustic spear]

Use file search and debug mode

These tools helps for sure

all what u need is to know the 1st class executed, then u can follow

[dark vigil]

That smells like bad package structuring to be honest.

[visual ravine]

⬆️
If you don't find a class, you probably badly symtructured you project

[gilded talon]

in larger code bases where you have hundreds of classes...

Thousands of types. And the answer is that it is a combination of:

• Sensible package and type naming so that it's obvious where to find a particular type
• A good IDE that makes finding things easy

[flint matrix]

You're right good package organization should help with this, but for people new to the codebase or doesn't have as much context should you explore before creating a new class

[gilded talon]

We try pretty hard to avoid using the same name twice for any type within the same namespace - so we can have two 'Foo' types if their visibility/context prevents them ever being ambiguous.

We don't generally have to think much about this because the natural names for the types and our patterns of naming mean there's rarely ever an overlap.

[pulsar kayak]

who cares

if you duplicate code thats fine

IDEs and all sorts of tooling can tell you if code is suspiciously similar to other code

but if they fail to find it big whoop