![]() | COBOL was one of the Engineering and technology good articles, but it has been removed from the list. There are suggestions below for improving the article to meet the good article criteria. Once these issues have been addressed, the article can be renominated. Editors may also seek a reassessment of the decision if they believe there was a mistake. | ||||||||||||||||||||||||
|
![]() | This ![]() It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||||||||||
|
![]() | The contents of the Picture clause page were merged into COBOL on 8 August 2014. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page. |
Index
|
|
This page has archives. Sections older than 31 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present. |
PERFORM is like GOSUB in BASIC, that does not promote modular programming. It promotes to divide de program in sections like additions, deletions and changes, very common in batch processing. That is not modularity. The lack of modular programming is the main problem of COBOL, it has PROCEDURE DIVISION USING to declare subroutines, but its verbose style, even using COPY files (similar to #include in C) is not easy to use. For that reason the statement "which promoted modular programming" may be changed to "which promoted to divide the program in sections" could a be better choice, but that can be confusing because SECTION is a keyword in COBOL which refers to a subdivision of DIVISION. Maybe "which promoted to divide the program in parts" could be better.
The article say:
That seem wrong to me, because the level 66 RENAMES corresponds to union
in C and Pascal's variant records.
It was used very often in old COBOL programs because data files were usually pouched in 80 column cards.
Records larger than 80 chars where stored in several cards, using a record id and one column to mark which part of the record it has.
Even today many programmers ignore how to use unions, but that is not a dangerous feature of any language that ought to be forbidden as is attributed to the book by McCracken.
I don't have that book to corroborate that. Other book by McCracken about numerical methods in Fortran was very popular in that time, I don't have it neither, maybe those books were written before structured programming became a standard. By 1988 it was broadly accepted to write structured programs and OOP started to gain popularity, but many programmers were still using data flow diagrams which incentive undisciplined use of GOTOs, and were reluctant to use structured pseudocode, particularly by programmers out of academy.
After reviewing this article, I am concerned that it no longer meets the GA criteria. My concerns are listed below:
Anyone interested in fixing up this article? If not it might be nominated to WP:GAR. Pinging the GAN nominator @ EdwardH:. Z1720 ( talk) 01:23, 26 May 2024 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This article contains a bloated lede (as well as other sections), an orange tag outlining missing information from 2021, and many uncited statements. I posted my concerns on the article talk page, but there was no response. Z1720 ( talk) 15:37, 5 June 2024 (UTC)