231–240 of 246 posts
Earlier quoted context omitted.
Totally agree with the point of pen/paper. Something that compliments that approach is in-code annotation. Recently, I've recently been trying out https://github.com/bastibe/annotate.el which is pretty sweet. Check it out!
Off topic, but anyone know what font and theme (it looks like the default theme but I'm not sure) are used in the project's screenshots?
Earlier quoted context omitted.
You remove the printfs when you have fixed the problem.
It's so tempting to do this. Don't. Problems may occur again in the same area. Leave your logging statements around; configure your logging setup to skip them when you don't want them. You're saying to delete commented-out code once the new code works. Put your code in version control instead. Logging is to once-off printfs as version control is to commented-out code.
sourcegraph.com can help.
Drawings will help tremendously. Extract the big masses, their respective interfaces to each others and the means through which they communicate. This will help build a mental map of the code and reduce the cognitive load needed to understand each separate part.
If the project does not have circular dependency, it can be automatically drawn from the code like this: http://lonnie.io/gostd/dagvis/ or this: http://8k.lonnie.io/
http://vcspull.readthedocs.org/en/latest/
I keep the applications I want to study in a YAML file (https://github.com/tony/.dot-config/blob/master/.vcspull.yam...) and type "vcspull" to get the latest changes.
You can read my ~/.vcspull.yaml to see some of the projects I look over by programming language. You can setup your config anyway you want (perhaps you wanted to study programming languages implementations, so have ~/work/langs and cpython, lua, ruby, etc. inside it.
Earlier quoted context omitted.
Some unit testing might be a joke, but not all unit testing. If you have small units-of-work they should be tested, or at least testable. Integration testing often makes a lot more sense, though.
I believe I'm in the minority, but I think unit tests are nearly universally worthless - exceptions being those for well defined APIs (eg math). Good unit tests must have an independent oracle of truth or else you aren't testing anything. As a practical matter you should only write tests for code that materially impacts the business (or you are just wasting everyone's time ). Instead of writing regression or integrat…
Earlier quoted context omitted.
It depends on what you're working on. If you're working on, say, a huge Java codebase, then a debugger is practically essential because you've got a lot of code to navigate, and you probably want to see what flavour of objects are being passed around and how their state is being updated. On the other hand, if you're working on, ooh, a Nodejs codebase, you're probably looking at less code, with a debugger that's much…
I'd argue that print statements are a debugger, albeit a custom one off debugger. Sounds like the actual debugger needs work (... or from my experience it's me who doesn't understand the debugger correctly)
Earlier quoted context omitted.
In my case, aggressively reject any printf statements in code review. Get that shit out of my repo.
Without trace statements, how do you diagnose issues that don't occur locally and only appear in the production environment.
Just plain "debug log statements" I have yet to hear a good use case for. Every time people have put them in, it's because some bug called for their inclusion, then the bug got fixed, then the statements got left around after the bug was fixed. Or the bug didn't get fixed and it's a matter of "why don't you fix the bug?"
There's rare cases where there's an ongoing issue with a known bug that you don't know the fix for yet, so you drop debug statements in production code hoping to catch it. But this is supposed to be a rare, rare case.
Earlier quoted context omitted.
> I try to understand the code and keep it in my memory so that I could predict the behaviour without the debugger. That's the theme I hear when prodding people who (sometimes loudly) say they don't use debuggers. They work on codebases that are either small, solo projects, or change very slowly. That way they can keep an accurate simulation of the entire program in their heads. Meanwhile, I've always worked on codeb…
Not necessarily. For instance, my colleagues work with a fairly large codebase in java which runs on top of a framework written in scala. When they tried to hook up a debugger it drilled the whole stack top to the bottom, naturally and showed them whole lot of scala code. Problem is, these guys don't now scala, only java.
I don't find it a hindrance in any way seeing what part of the Django code called my code.