Show HN: Codemodder – A new codemod library for Java and Python (opens in new tab)

Hi! Great questions. I'm the lead maintainer of the Python version of the Codemodder framework so I'll do my best to answer.

> How does libCST compare to e.g. pyCQA/redbaron?

LibCST is similar to redbaron in the sense that it does preserve comments and whitespace. The "CST" in LibCST refers to "concrete syntax tree", which preserves comments and whitespace, as opposed to an "abstract syntax tree" or "AST", which does not. Our goal is to make the absolute minimal changes required to harden and improve code, and messing with whitespace would be counter to that goal. It's worth noting that redbaron no longer appears to be maintained and the most recent version of Python that it supported was 3.7 which is now itself EOL.

> What about for EA Evolutionary Algorithms

Can you elaborate? I am familiar with the concept of evolutionary algorithms but I'm not sure I understand what you mean in this context.

> does it preserve comments, or update docstrings and type annotations in mutating the code under test?

Codemodder does preserve comments. Currently none of our codemods update docstrings; I'm not sure we currently have any cases where that would make sense. We do make an effort to update type annotations where appropriate.

> Is it necessary to run `black` (and `precommit run --all-files`) to format the code after mutating it?

Yes, it is currently necessary to run `black` and `precommit` if you're using it on your project. While `black` is incredibly popular, we also can't assume that it's being used on any given project. Running `black` would cause each updated file to be completely reformatted which would lead to very noisy and difficult-to-review changes. I would like to explore better solutions to this issue going forward.

I am familiar with `bandit`. It's a fairly simple security linter and is useful for finding some common issues. It's also pretty prone to false positives and noisy findings. Not every problem identified by `bandit` is something that can be automatically fixed; for example I can't replace a hard-coded password without making a lot of (breaking) assumptions about the structure of your application and the manner in which it is deployed.

I'd love to get your feedback on Python Codemods! Give us a star on GitHub and feel free to open an issue or PR: https://github.com/pixee/codemodder-python

Grit looks cool! My apologies for the omission, I was unaware of it. I could have anchored too hard to the word "codemod" in my searches. Your tool looks awesome!

> Do you have an example of how you inject context into the codemods?

When you say "context", I want to make sure we're talking about the same thing, and the question makes me think we're not there yet. We're basically saying that storytelling about the changes is very important, so we bake invariance into the APIs of codemods themselves, so codemod authors are forced to provide descriptions, reasons, justification -- whatever -- at the key points.

Codemodder and SpongePowered Mixin cater to different scenarios. Codemodder is ideal for transforming source code you own, based on specific patterns. Changing source code allows the changes to be tracked, reviewed, and analyzed using standard tools like compilers and static analysis. It's great for large-scale codebase refactoring.

Contrastingly, SpongePowered Mixin uses Java bytecode manipulation, to transform the bytecode of a specific type. Bytecode manipulation comes with added risks and complexity, so this method is typically reserved for when you need to change the behavior of some external library or framework type. For example, Mixin is useful in Minecraft modding, because it allows modders to change the behavior of externally defined Minecraft types.

In essence, choose Codemodder for large-scale refactors to your source code, and Mixin to modify the bytecode of external Java types.