Wikipedia:Peer review/COBOL/archive2

COBOL

Previous peer review

This peer review discussion has been closed.
I've listed this article for peer review because I believe its nearly ready to become a GA. However, I've had little interaction with other editors, and I'd like to get other people's suggestions on how to improve it first.

Thanks, EdwardH (talk) 19:49, 2 January 2015 (UTC)

Qwertyus' comments

• I don't understand the Aggregate data section. Records, elementary items and group items are defined, then an example is given, but the text after the example does not explain which parts of the example are records, elementary or group items. Also, the grammar in "Data items containing subordinate items which are not subordinate to another item" is awkward. I suppose this means something like top-level items in the hierarchy of items, but it could just as well refer to subordinate items that are subordinate to the first set of items, but not to any other items (if the hierarchy of data items were a DAG, think multiple inheritance). QVVERTYVS (hm?) 20:27, 6 January 2015 (UTC)

I added notations to the first code fragment example to help make things a little clearer about "aggregate" and "elementary" data items. — Loadmaster (talk) 23:08, 29 January 2015 (UTC)

• The Procedure division section needs some work. I think control flow might be moved before procedures, because the latter presupposed that the readers knows what a GO TO does (which I think the youngest generation of beginning programmers might not know...). Also, the explanation of "mines" is a bit incomplete. Do I understand correctly that when execution reaches the end of a function, it reaches the next function (in textual order) instead of the caller? QVVERTYVS (hm?) 20:41, 6 January 2015 (UTC)

@Qwertyus: thanks a lot for the comments and edits! I'll work on the Aggregate data and Procedure division sections ASAP. Regarding execution: yes, it will try to "fall into" the following procedure in the source. However, when the procedure(s) have been reached via a PERFORM, execution will return to the caller at the end of the (last) procedure. By the way, how effective do you think the diagrams in section Procedures were in illustrating control flow and mines? EdwardH (talk) 20:33, 7 January 2015 (UTC)

The left one caught my eye and got me reading the text. The right one is less clear, I think, unless you already know how a procedure call works in pretty much any other language, in which case it isn't a very interesting diagram. QVVERTYVS (hm?) 20:46, 7 January 2015 (UTC)

@Qwertyus: thanks, I'll get rid of the rid of the right diagram then. EdwardH (talk) 17:29, 8 January 2015 (UTC)

Loadmaster's comments

• We need to make it clear that in pre-COBOL-85 code, all paragraphs and sections were performed via a separately-located PERFORM statement, and that COBOL-85 introduced inline PERFORM (looping) statements. The inline syntax allows the control flow to be more obvious, in that the body of a code loop is located inside its controlling PERFORM verb, instead of being located apart from the PERFORM in another paragraph elsewhere. — Loadmaster (talk) 23:14, 29 January 2015 (UTC)

 Done

• Also, the proper terminology is "section" and "paragraph", not "function". The closest analog that COBOL has to procedures or functions (as understood in current programming parlance) is the entire PROCEDURE DIVISION of a separate (sub)program module. — Loadmaster (talk) 23:18, 29 January 2015 (UTC)

✗ Not done @Loadmaster: Firstly, thanks for the comments and edit! (And so soon, too.) But where do you think "function" is being misused? It all looks fine to me. EdwardH (talk) 20:57, 30 January 2015 (UTC)