Live data from Hacker News

On navigating a large codebase

blog.royalsloth.eu

121–130 of 139 posts

Re: On navigating a large codebase

#121

This is a great article. I felt like it was describing a job I recently left, especially this piece: > It’s fine to have less experienced people working on a large system as long as they have the elders overseeing their work. In the world where senior titles are handed left and right, that is often not the case and it’s how you end up with a very fragile system that is suitable for a replacement as soon as it was bui…

Gaming company in San Mateo? Lol

Re: On navigating a large codebase

#122
post #112

Well, that's a surprise for sure. I wrote this article a few months ago and it gained no traction. Today I woke up and boom, front page.

I really connected with the writing. Thank you for taking that time. There is a lot in my current context the writing resonates with. Nice to find that others have been on this path too, and that we benefit from a lot of the same techniques. Thanks for putting this out there as an invitation to draw people together.

I am glad you liked it.

Re: On navigating a large codebase

#123
post #32

Earlier quoted context omitted.

> Code comments? Nah. This is one of my biggest gripes. Someone (I think uncle bob) said that good code is self-documenting, which is bs in 95% of the cases. Yeah, you don't need to document the convertMinsToSecs() method, but most real life codebases are full with edge cases, shortcuts, temporary solutions, half-complete reorganizations. So people use this for writing no comments at all, whereas a few words of comme…

While I agree to some extent, the problem with comments is that they need to be maintained in order to be helpful: code comments - updated when the code changes, general comments - when the context changes, etc. This is a work in itself: developer has to remember to do it, reviewer has to remember to look for it. In my experience, people tend to forget to do it or just don't bother, which means that someone else find…

Sure but which is more likely:

Someone updating the comments in code that they are updating because they see the comments right in front of them.

Or

Someone going to look through the documentation to see if there is anything relevant about the code they are working on that needs to be updated.

Re: On navigating a large codebase

#125

Earlier quoted context omitted.

I'd much rather have a million lines of Java. And I'm not a huge fan of Java. It can be a bit tedious going down the AbstractWidgetInterfaceFactoryFactory rabbit holes, but at least I have a fighting chance.

To each his own...

Honestly they both sound horrific. Any code base that large ...

Re: On navigating a large codebase

#126

This is one of the big reasons I prefer static typing. When looking at some unfamiliar code in an unfamiliar codebase, I can reason about the code much faster when I can see what functions return, and quickly go check their types out if the type is unknown. This makes me much more productive. I helped maintain a 250kLOC Python program. I came in when it already at over 200kLOC. I spent so much time , every time, just…

250kLOC Python sounds scary. But that would easily be 1mLOC+ lines in Java ...

Not necessarily. It's possible to write quite terse code in Java, especially Java 10+ (var, streams, etc.). And now with records and pattern matching, even more so.

Re: On navigating a large codebase

#127
The two best bits of advice I got about writing code when I started were: 1) start off by saying what you're doing and 2) the is always an 'Else'. "If you can't say in words what your method/function/class/... is doing you probably won't code it right either." Sure I'll leave if off simple stuff but it's really helps me keep focused. And when the debugger suddenly drops me into the middle of something it's a lot faster to scroll to the top to see what is supposed to be going on.

I also agree that's it's complete macho crap about not needing comments. Hell I come back to something I was working on six months ago and don't remember what I was doing. Far better to have some comments telling me than spend time looking back over more code to figure out what this piece is supposed to be doing.

Re: On navigating a large codebase

#128

This is one of the big reasons I prefer static typing. When looking at some unfamiliar code in an unfamiliar codebase, I can reason about the code much faster when I can see what functions return, and quickly go check their types out if the type is unknown. This makes me much more productive. I helped maintain a 250kLOC Python program. I came in when it already at over 200kLOC. I spent so much time , every time, just…

250kLOC Python sounds scary. But that would easily be 1mLOC+ lines in Java ...

I don't understand why people say this about Java and C# vs. Python. You can easily write concise code. There will be more lines because of things like brackets and some other simple things, but c'mon, it's not 2005.

Re: On navigating a large codebase

#129

Earlier quoted context omitted.

While I agree to some extent, the problem with comments is that they need to be maintained in order to be helpful: code comments - updated when the code changes, general comments - when the context changes, etc. This is a work in itself: developer has to remember to do it, reviewer has to remember to look for it. In my experience, people tend to forget to do it or just don't bother, which means that someone else find…

Sure but which is more likely: Someone updating the comments in code that they are updating because they see the comments right in front of them. Or Someone going to look through the documentation to see if there is anything relevant about the code they are working on that needs to be updated.

Somewhat surprisingly, it depends. For instance, in our case application support is responsible for/interested in the documentation, and they make sure that developers create/update the relevant documentation for each of the release items. Stale comments, on the other hand, need to be identified and addressed in code reviews, and in practice we're not always good at that.

Re: On navigating a large codebase

#130

The article mentions the importance of comments and documentation inline in code. I tend to agree - well-written code is great and all, but a good comment can bring in context external to the code and make _why_ code is what it is more clear to future readers. And reviewers. Comments explaining _what_ code does largely aren't needed - that's evident from usage. But the _why_? Some people would say code which can't be…

Please, please comment code. Junior devs like myself will thank you senior devs for throwing us a bone.

As do us old senior contracting devs who have to come in at short notice and pick up a strange codebase.
Post reply on HN