Repo clean-up

Question

Repo clean-up

mwjames opened this issue 8 years ago · 10 comments

This repo requires some general clean-up to conform with the https://github.com/SemanticMediaWiki semi maintenance standards:

Objectives

Travis and unit tests to target test coverage 80%+
Scrutinizer > 9
Composer + PSR-4
Namespace usage (SCQ)

Code

SCQCompoundQueryApi not sure why this is called compoundquery as API module. I understand the compound part, the query part not so much, it is so generic that it doesn't allow to associate it with #ask and this clearly uses the #ask syntax (extended with SCQ syntax elements). Without knowing compoundquery it could be a SPARQL query, or SQL query but in fact it is a #ask query therefore I'd rather see it named compoundask to reflect the intention of this module.
SCQQueryProcessor has a lot of static methods that makes it difficult to test (at best)

i18n

Not my topic @kghbln ?

Answer 1 · 2016-07-01T08:24:34.000Z

I18n is cool!

Answer 2 · 2016-07-01T08:54:05.000Z

About SCQCompoundQueryApi, see the discussion in https://github.com/wikimedia/mediawiki-extensions-SemanticCompoundQueries/pull/1.

Answer 3 · 2016-07-01T12:14:57.000Z

I added some unit tests in #7.

Answer 4 · 2016-07-01T14:38:53.000Z

About SCQCompoundQueryApi, see the discussion in wikimedia/mediawiki-extensions-SemanticCompoundQueries#1.

I saw the discussion but that was before it was part of the https://github.com/SemanticMediaWiki repo so, for the given reason I'd like to see that reconsidered.

Answer 5 · 2016-07-01T14:43:05.000Z

I'm open to changing the name to compoundask.

Answer 6 · 2016-07-02T18:44:26.000Z

How about giving @PeterTheOne admin access to this repo? Ping @yaronkoren

Objectives

muh... while I appreciate the intent here, I really don't like that list. Code coverage is a bad goal. So is Scrutinizer. The cleanest non-trivial PHP codebase I know barely makes it over 9/10, with the points it loses all being things that are either false positives or not worth bothering about.

    Usable Software Design means to us that

        It is written for developers to read
        It is easy to find where to modify the code
        Any modification has a minimal ripple-effect
        It is easy AND fast to validate that we did the right thing
        We don’t have to do similar modifications in several places

Source http://mozaicworks.com/blog/smart-people-explore-usable-software-design/

Answer 7 · 2016-07-02T21:01:08.000Z

muh... while I appreciate the intent here, I really don't like that list. Code coverage is a bad goal. So is Scrutinizer.

I heard those arguments before and that applies to certain groups of projects but without any quantifiable objective, argumentation about "bad" or "good" is just an empty word phrase that cannot be compared to any yardstick. Instead of repeating something developers find inappropriate for their environment, I'd see a minimum of quantifiable standards (and the simplest without making things difficult for any anyone are numbers reported by Scrutinizer and Code coverage) be applied.

Whether those numbers can really reflect "good" from "bad", "trivial" from "non-trivial" isn't part of the issue nor of the overall objective to allow for some "semi maintenance standards".

I have cited [0, 1] in the past, and it is the responsibility of the developer to fill to void and not just hunt for a numbers. Those numbers can give some guidance for a project nothing more and nothing less.

[0] http://blog.ploeh.dk/2015/11/16/code-coverage-is-a-useless-target-measure/
[1] http://martinfowler.com/bliki/TestCoverage.html

Answer 8 · 2016-07-03T23:20:03.000Z

Guidance can be very harmful if it is bad :)

Answer 9 · 2016-07-05T19:55:35.000Z

What is still open here? Should we do the rename to compoundask?

Answer 10 · 2016-07-06T02:06:37.000Z

I like compoundquery more. It's in line with the name of the extension.