Htydjtk

Journals consider that is good practice to release script and codes to repeat the published results, and many of us I think agree with this practice. Code are typically deposited in software version control repositories (e.g., GitHub or BitBucket).

I wonder if updating the codes during reviewing process or after publications (which in my opinion is quite important, in general) remains a good practice.
Maybe the obvious answer is yes, but for example it is certainly not good to modify the data deposited for a published article (or modify its pre-print in a pre-print server).

Absolutely yes! There is no reason to stop a project from evolving just because you've published about it.

What would be good to do, however, is to identify the version current at the time of publication with a release version or other similar sort of tag. You can point to the specific tag in the publication and also have the repository tag point to the publication through its associated comment text.

This will allow a reader to have the best of both worlds: access to both the most updated information and also to the precise version associated with the publication if they need it.

It all depends. For minor changes or fixes (version upgrade, typos corrected), you should go ahead with the edits without an apology. But if your original code contained errors, you should document the changes and leave the original code with the errors somewhere for the record. Make two directories, clearly named with a date and/or version number and explain clearly in a README.txt file that there are several, quite distinct versions, and explain how they differ. Name anyone who may have been involved in discovering errors or problems.

If you can improve your code, you have a duty as a programmer to do so. However, you need to be aware of what kind of changes you are making:

1) Corrective Change. if you are changing a part of your logic and algorithms, specify that it is changing, as the results will also change. Re-run of the experiment is required.

2) Perfective: Make the code faster or more efficient. This does not change the data, but looks nicer. Re-run of experiment is required if the data changes.

3) Adaptive: Change the input or run-time environment. For example, a hardware change may necessitate a change in the software. This only requires re-running the experiment if the input data changes.

4) Disconnected/preventative: Change the underlying model that your code is based on. Re-run is required.

If a re-run is required, specify this in documentation as previous results will be useless. If you make significant changes to the underlying model or the performance, publish a separate paper about it, specifying that it is an up-to-date version of the old one, and self-cite the original code. Include what was improved and changed, especially if it is performance related.

system/app/MTKLogger/MTKLogger.apk 

/*