Skip to content

Conversation

@hiker
Copy link
Collaborator

@hiker hiker commented Oct 18, 2017

accepted. Added test case for usage of '::", and also test cases
for module procedure declaration without the (optional) 'module'.

accepted. Added test case for usage of '::", and also test cases
for module procedure declaration without the (optional) 'module'.
@coveralls
Copy link

Coverage Status

Coverage remained the same at 82.104% when pulling 0ce238a on hiker:fix-issue-45 into 3cc5c52 on stfc:master.

@arporter arporter self-requested a review October 18, 2017 08:24
Copy link
Member

@arporter arporter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think \s should be used in the regex rather than " " but apart from that changes are good. Relevant test is extended and still covers the only changed line.

Only significant issue is that we are trying to improve the code base and therefore we apply our coding rules to any changed routines. This means that the test routine needs a doc string and some other minor changes.

[ MODULE ] PROCEDURE [::] <procedure-name-list>
"""
match = re.compile(r'(module\s*|)procedure\b',re.I).match
match = re.compile(r'(module\s*|)procedure\b *(::)?',re.I).match
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should that be "\s*" rather than " *"?

'module procedure :: a '), 'MODULE PROCEDURE a')
assert_equal(parse(ModuleProcedure,\
'module procedure :: a , b'), 'MODULE PROCEDURE a, b')
assert_equal(parse(ModuleProcedure,\
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extend existing test to check that fparser is happy with/without the "module" prefix and/or the "::" separator. Great.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per the review guidelines (https://github.com/stfc/fparser/wiki/CodeReview), please could you update this routine to be pep8 and pylint compliant (i.e., two blank lines before and after it, a docstring etc.). Also, we're trying to move away from using nose so please could you replace all uses of "assert_equal" with just "assert" in this routine.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 82.104% when pulling 110a8b2 on hiker:fix-issue-45 into 3cc5c52 on stfc:master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 82.104% when pulling fb97013 on hiker:fix-issue-45 into 3cc5c52 on stfc:master.

@hiker
Copy link
Collaborator Author

hiker commented Oct 19, 2017

OK, I did most of it (see also pull request coding style - which might have some minor conflicts with this one).
Some pylint warnings are REALLY annoying, e.g. 1 letter variable names. Amd I am not even sure if we need docstring for each function (each class will have a tofortran function (64 in statements.py) and analyze (58) ) - does it make sense to document them all just to keep pylint happy?

@arporter
Copy link
Member

Wow, you didn't need to do the whole file but thanks very much! Changes in this PR are now all good.

@arporter arporter merged commit 07694ff into stfc:master Oct 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants