Improve Code Readability and Aesthetics

[kripken]

Help with making the code prettier would be great. It is really easy to improve this, just changing function names would be a good start. Bigger refactorings are also possible of course.

Emscripten has tons of automatic tests, so we can make these changes with no risk of regressions.

The reason I don't do more of this myself, is I am too used to the code to know what stands out as unreadable and in need of cleanup.

[crgosselin]

Hey Kripken, definitely willing to go through it all and start making it more aesthetically pleasing. As you said, I think it'll be a nice start to diving into the project. Cheers

[kripken]

Hey crgosselin, that would be great! Let me know if I can help explain stuff in the code that isn't clear.

Note that all new development is currently being done on the llvm-svn branch - which should merge soon to master. So best to work there, although likely there wouldn't be a problem anyhow.

[haneefmubarak]

If no one is working on this bug, may I take it as my first bug?

[kripken]

Feel free to help out here. I guess this bug is very old though and very general, it might help to focus on some specific area in the code.

[haneefmubarak]

Hey, I need some help with a few things before I start, so could we chat, perhaps on freenode or something?

[haneefmubarak]

Actually, here are the things I'd like:

• A branch on the main repo that I can push to (or something that automatically pulls from my branch) - cleanup sounds good
• A basic description of what is in the various directories - oneliners for each should do it
• A list of external dependencies for the testing suite (if any)

That ought to be all for now.

[kripken]

I am often on the emscripten irc channel, we can talk other. others that know about the code are there as well.

Not sure what a new branch would help, that pull requests do not do?

Main dirs:

• cmake - not sure, cmake people would know
• docs - documentation
• patches - old, can be removed or moved somewhere less prominent perhaps
• scons-tools - not sure, scons people would know
• src - main JS compiler
• system - system headers, libraries, etc.
• tests - test suite
• third_party - code under another license than ours that we use, like closure compiler
• tools - utility scripts, toolchain stuff

Test suite depends on the usual stuff as normal emscripten, but it does use all code paths. So it needs things like crunch. I can't think of anything else offhand.

[juj]

The cmake directory contains the compiler toolchain definition file for
Emscripten for CMake - also, the directory structure inside that directory
needs to be specific like it is due to hardcoded requirements in CMake
itself. CMake is used with the 'emconfigure cmake' command line to
configure build system from CMakeLists.txt files.

The Scons directory is similar, but for the Scons build system.

2014-02-24 22:42 GMT+02:00 Alon Zakai notifications@github.com:

I am often on the emscripten irc channel, we can talk other. others that
know about the code are there as well.

Not sure what a new branch would help, that pull requests do not do?

Main dirs:

• cmake - not sure, cmake people would know
• docs - documentation
• patches - old, can be removed or moved somewhere less prominent
  perhaps
• scons-tools - not sure, scons people would know
• src - main JS compiler
• system - system headers, libraries, etc.
• tests - test suite
• third_party - code under another license than ours that we use, like
  closure compiler
• tools - utility scripts, toolchain stuff

Test suite depends on the usual stuff as normal emscripten, but it does
use all code paths. So it needs things like crunch. I can't think of
anything else offhand.

Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-35933604
.

[haneefmubarak]

@juj Would it be possible for the cmake and scons-tools directories to be shifted into a build-tools directory?

[juj]

Is there a need to do that? I would not like to do so, as it could break existing toolchains people may have set up.

[haneefmubarak]

@kripken Having a branch would make it much easier to work with as master and incoming will likely diverge fairly often from cleanup and merging back into incoming will likely become less frequent as time goes on.

Also, as more significant changes start to occur, it may be useful to allow others to work on cleanup too.

[haneefmubarak]

@juj The top level directory is fairly crowded, to be honest. Although it may break up a fair number of toolchains, fixing said chains will be trivial as only the path would need to be edited.

[haneefmubarak]

@kripken Could you assign me the bug? thx.