FreeCodeCamp has an excellent and superbly-paced+interactive graded JS course (graded = beginner, intermediate, advanced altho I'm sure someone will want to quibble with those designations)
FreeCodeCamp has an excellent and superbly-paced+interactive graded JS course (graded = beginner, intermediate, advanced altho I'm sure someone will want to quibble with those designations)
One of my old jobs was to reverse engineer minified JS — it is indeed a pain. Injecting debugger statements and switching between Firefox and Chrome were probably the two biggest helpers....
One of my old jobs was to reverse engineer minified JS — it is indeed a pain. Injecting debugger statements and switching between Firefox and Chrome were probably the two biggest helpers. Switching browsers helps since they both have their strengths in their debuggers.
I'm regularly working with an application-specific proprietary procedural language, and recently had to rewrite a thousand lines of uncommented code. It was written a couple of application...
I'm regularly working with an application-specific proprietary procedural language, and recently had to rewrite a thousand lines of uncommented code. It was written a couple of application versions back, and handled data with direct database calls using an old and now incompatible data model. The programmer who wrote it was a wizard no one else could keep up with, and left ten years ago.
I wound up going through every step in this tips list... The rewritten code (down to 150 lines because many of the functions have been rationalized or split to dedicated external applications) goes live in the field next week. Aside from hoping I haven't missed anything in testing, I'm praying that someone 10 years from now isn't cursing my name the way I cursed the previous writer.
At my current job, there's tons of uncommented, undocumented code written by people who have left the company some years ago. I've commited that with every bug report, I will fix the bug and...
At my current job, there's tons of uncommented, undocumented code written by people who have left the company some years ago.
I've commited that with every bug report, I will fix the bug and refactor that code into a function with a docstring, and usage instructions. New functionality will be documented in our knowledge base, and end users will have easy to understand instructions.
However progress is slow. I don't want to fix what ain't broke, so there's still lots of code that isn't documented or even readable, but with time I will get there.
I'm also working on a new piece of software. I've documented the shit out of it, hoping that the next person to work on it will have an easier time on this Earth, but who knows.
Now I need to figure out how to make my colleagues write good documentation without being annoying about it. And also train future generations about writing readable code and documenting it. Otherwise in a couple of years we'll end up back where we started.
Interesting article. I think reading and understanding code is just as important as writing readable code. I also wrote an article about that (kind of) and I can recommend the book "The...
Interesting article. I think reading and understanding code is just as important as writing readable code. I also wrote an article about that (kind of) and I can recommend the book "The Programmer's Brain" by Felienne Hermans if you want to get better at it.
you can use statistical analysis to guess the names of variables: http://www.jsnice.org/
I agree with your silver lining.
I can't even read my own PERL programs from a few years back.
FreeCodeCamp has an excellent and superbly-paced+interactive graded JS course (graded = beginner, intermediate, advanced altho I'm sure someone will want to quibble with those designations)
Aren't there like apps or scripts that can help de-compress and make sense of all that?
Babel is a transpiler which can convert Javascript to Typescript, they must give it a try if they haven't already.
One of my old jobs was to reverse engineer minified JS — it is indeed a pain. Injecting debugger statements and switching between Firefox and Chrome were probably the two biggest helpers. Switching browsers helps since they both have their strengths in their debuggers.
I'm regularly working with an application-specific proprietary procedural language, and recently had to rewrite a thousand lines of uncommented code. It was written a couple of application versions back, and handled data with direct database calls using an old and now incompatible data model. The programmer who wrote it was a wizard no one else could keep up with, and left ten years ago.
I wound up going through every step in this tips list... The rewritten code (down to 150 lines because many of the functions have been rationalized or split to dedicated external applications) goes live in the field next week. Aside from hoping I haven't missed anything in testing, I'm praying that someone 10 years from now isn't cursing my name the way I cursed the previous writer.
At my current job, there's tons of uncommented, undocumented code written by people who have left the company some years ago.
I've commited that with every bug report, I will fix the bug and refactor that code into a function with a docstring, and usage instructions. New functionality will be documented in our knowledge base, and end users will have easy to understand instructions.
However progress is slow. I don't want to fix what ain't broke, so there's still lots of code that isn't documented or even readable, but with time I will get there.
I'm also working on a new piece of software. I've documented the shit out of it, hoping that the next person to work on it will have an easier time on this Earth, but who knows.
Now I need to figure out how to make my colleagues write good documentation without being annoying about it. And also train future generations about writing readable code and documenting it. Otherwise in a couple of years we'll end up back where we started.
Interesting article. I think reading and understanding code is just as important as writing readable code. I also wrote an article about that (kind of) and I can recommend the book "The Programmer's Brain" by Felienne Hermans if you want to get better at it.
We should all seek to understand first and be understood second in many areas in life and code