Please do not play cookie cutter with my replies.
Despite any agreement, you continue to
link your own pages around as if the community article did not exist. If this becomes commonplace, then there really is no point in having a wikipedia for the site. The articles available become the loosely affiliated, decentralized opinion of a few key individuals (especially that of the so-called "goddess" who basks in her own hype) instead of a group concensus.
There is no sense in having a wikipedia if there can not be any group concensus over such a stupid issue. That confirms your belief it is perfectly okay to just ignore the community regarding any issue at all, and use it as a platform for your own ideas when people disagree with you. Until we have a public article based upon mutual agreement the subject at hand deserves not to be covered.
Publish your thoughts somewhere else if you are too lazy to take matters into your own hands and fix what's already been written in the community article. I'm urging you to take laserlight's advice. How about you merge it somehow, and then let the interested parties react. I'm sure that we are all smart enough to write something to everyone's satisfaction. It won't kill you to critically review your article, anyway; through revision, you may find a clearer, concise way to help individuals through the main article.
I agree that the main article has shortcomings. For example, the examples section is particularly thin, but I didn't want to judge it myself, because it really hung on how effective the text communicated the idea. After all, as long as the text was understood, the difference between poorly indented and well-indented is obvious; the benefits, obvious.
If you want to teach people the point-of-view of an experienced person, than take a sample program such as this:
Code:
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
void process_file ( char * longOrderID, size_t bufsiz, FILE * file );
int
main ( int argc, char * argv[] )
{
if ( argc == 2 ) {
char longOrderID[BUFSIZ];
FILE * fin;
fin = fopen( argv[1], "r" );
if ( fin != NULL ) {
process_file( longOrderID, sizeof longOrderID, fin );
puts( longOrderID );
fclose( fin );
} else {
perror( argv[1] );
}
} else {
puts( "incorrect number of arguments--provide a file to read" );
}
return 0;
}
void
process_file ( char * longOrderID, size_t bufsiz, FILE * file )
{
char * p = longOrderID; /** position in longOrderID **/
char * nl = NULL; /** find newlines **/
size_t read;
strcpy( p, "Value=" );
read = strlen( p );
p += read;
bufsiz -= read;
/** read in chunks: **/
while ( bufsiz > 0 && fgets( p, ( int )bufsiz, file ) != NULL ) {
if ( ( nl = strchr( p, '\n' ) ) != NULL )
*nl = '\0';
strcat( p, "," );
read = strlen( p );
p += read;
bufsiz -= read;
}
}
And use it as the visual aid to explain as you see fit: refer to line numbers like they do in books if you must. I'd use the principles set forth in the community article.
You probably have structural changes you'd like to see; you're free to make them. I just don't want the neutrality of the article completely destroyed. The code above is as well indented if it were written like Whitesmith's, where your paltry "+1 indentation level" rule doesn't exist. The brace placement you suggest is not applicable, because the brace is in the same character row as any statement in the block. You have to be sure that the principles you espouse are in the right place, and expand beyond what is "simple," because oversimplifying is intellectually dishonest.
Originally Posted by Adak
