List of issues
If you are looking for the decompiler itself, visit https://github.com/jindrapetrik/jpexs-decompiler
#193 Rename all identifiers
Would be nice to have this to force names deobfuscation when Rename invalid identifiers fails at obfuscated names detection. Maybe rename "Rename invalid identifiers" to "Rename identifiers" and new checkbox "Rename invalid only" enabled-by-default in the Rename identifiers dialog would be more user-friendly?
"when Rename invalid identifiers fails" I think rename invalid identifiers should not fail at all. If it fails, that means there is a bug or it is not implemented very well. I don't think it is good idea to rename all, why would user need that? If there are some valid identifiers, it is good to leave them as is. Actually, my goal is to make renaming invalid identifiers feature working in 100% of cases.
Well, how would you determine such obfuscated names: "potato", "parrot", "car", etc.? I know obfuscators renaming identifiers in such manner - so the full rename could help here since "package_1" and "Class_1" is much better than abstract "parrot" and "car".
hmm, okay, I will consider adding "rename all by type" feature. But personally I will rather have parrot and car classes, than 100 classes named class_1,class_2...class_255, because they are easy to distinguish and remember even if they do not have names suggesting their functionality.
yeah, in my example it could be so, but there could be much more hard to remember combinations, like sunMoonLightDark, sunLightMoonDark, sunMoonDarkLight. darkMoonSunLight, lightMoonDarkSun, etc. I'll be glad to have an option for converting all this names into var_1, var_2, etc.!
I was thinking a little... There is a problem. It won't be so easy as it looked like for the first time. If I rename all identifiers, then all flash built-in packages/classes (ByteArray,SpriteAsset,...) will be renamed too. I need to somehow detect that name is built-in and then not rename it. That is probably easy for class names which have always "flash.*" package, but what about inherited methods? I have to decide whether a method comes from this class or is an overriden version of built-in class? Overriden methods have override flag so I can see that it comes from parent class... but then I must traverse all ancestors of the class ... This one is hard so please be patient. I am setting state to "new", but it has low priority, sorry.
Thanks for your explanation and no worries - take your time, there is no any urgency for this issue and I completely understand you have other issues with higher priority for now. Hope, you'll have some good solution for this built-in names detection, will wait for any news on this issue!
Any news on it?