Tagged: development

I have a love hate relationship with Bash. On one hand, I have a lot of scripts still running on it. On the other hand, almost all of them were started before I consciously decided that for most things I'll switch to Python. Here are 5 problems that I see with Shell programming:

After the article from yesterday where we got to see some code where code duplication actually improved the tests, we'll look at something similar today, but this time in unit tests, and why I'm not a big fan generally speaking of test parametrization.

This time we're going to look at a simple example of well written, compact code, and make it larger. And better.

Ok, we have now a new function with our own code in vim. We can manually trigger it when opening a buffer. Let's make this function automatically be called whenever opening a file, and fiddle with file types.

I love vim. And one of the reasons that makes it so appealing is customization. One of the coolest things is the ability to create functions. You bind the functions to commands, and you simply call the commands for the execution.

We're almost done. We covered how to build the project, how to navigate around it using grep, ctags and UML, and also how to approach finding out the issue in a structured approach. The last step is to plan for the future, and document our findings.

Now that we have ways to build the software when we change it, navigate around code, and fuzzy search through it, let's see how we approach specific problems, and use UML to chart this map.

As we discussed last time, we have the basic commands for searching around random files. Before dwelling into IDEs, for files that have a more esoteric language, CTags is the answer.

After we can build our code, it's time to start addressing making changes. Now, not all code is created equal, and there are better ways to move around than simply opening every single file. Let's see how.

In the next miniseries of articles we're going to deal maintaining Legacy Code. We'll go with how to absorb faster bigger portions of code, how to reason larger codebases, and general day to day life. Since there's no one size that fits all, your mileage will vary.