Refactoring for tests and advanced debugging

[florianb]

I could imagine a refactoring of the Linter, to have a more robust interface, detecting weaknesses in the linters (providing a usable debug-information, which may be reported), being fully test-suited and well-documented. As long as the whole system isn't too big it should be done in effortable time.

❓

[iam4x]

Yes, I agree! We should start doing it on a new branch. But someone need to drive the project with good practices and a good software architecture

[florianb]

I'm somewhat experienced in creating distributed architectures but I guess I'm not fully aware of the coffeescript/js/atom-framework capabilities. I would like to suggest creating a AtomLinter/linter-core-repository to standardize the repo-naming.

I would also like to suggest using GitHub to collaborate in the design-process - every idea to improve something is welcome. I could imagine the following tasks for the first milestone:

• requirement for publishing: code-coverage (with karma & jasmine) != 1.0
• full test-set for linter-core and linter-prototype (the new baseclass for linters, to be forked)
• a toggleable, scrollable bottom-info-pane for project-based configuration, debug-reporting, release-notes and project-announcements.
• a backward-compatibility-class "Linter", to catch up the old linters
• the polished, transparent, hovering lint-reporter next to the cursor

[park9140]

We need to start a branch to pull in the standard atom testing framework. They have it set up with jasmine and fully ready for integration style testing. So there shouldn't be any real difficulty testing the existing implementation.

[florianb]

Yeah, we should use the existing test-infrastructure. But we should probably also consider a refactoring of the classes and their responsibilities, to make the behaviour more consise and robust.

[park9140]

Agreed. I think our primary initial goal should be to force a solid mvc separation and get the views broken out from their controllers. The pattern for separating along these lines in most of the atom code doesn't really seem to exist. I'm still researching good methodologies for breaking it out.

[florianb]

👍

In my 2nd package (gradle-ci) - i made good experience with a nearly rails approach: having a model and medium-weight views. I think it is possible to create a fully working mvc-approach if that is what we're searching for.

I'll create a discussable skeleton to let the idea become more precise.

[lijunle]

I am suggesting to use Promise/A+ pattern to replace the callback pattern. The current code is very hard to find out what is dealing with the callback.

http://promisesaplus.com

[park9140]

Promises, yes please,
I use Q and find it very pleasing :)
https://github.com/kriskowal/q
@lijunle do you want to tackle refactoring some of the callback hell?

[hd-deman]

+1 q

[iam4x]

I use RSVP, but I'm okey with Q ;)

That's a good direction.

[lijunle]

@park9140 , I will do it if you guys accept the code.