0 Members and 1 Guest are viewing this topic.
Negative/rude/destructive comments towards someone's project or program based on file size, amount of sub-programs, programming language/libraries used or coding methods in an attempt to discourage the author of the said program. Criticism should be intended to make the person's program better in its current form.
Personally, I don't mind this new rule, as long as we're still allowed to voice our opinions calmly and positively towards how a coder should (in the mind of the person telling what they thinks) go about programming and if they should ask for others to optimize. Barring the talk of this sort completely will ensure that coders never will hear alternatives of how to develop software and how to ask for help in more constructive ways, sealing the stream of the learning process from one of it's tributary sources.
2: Negatief/onbeschoft/destructief commentaar op iemands project of programma gebaseerd op bestandsgrootte, aantal subprogramma's en programmeertaal/~bibliotheken, met de bedoeling de auteur van het genoemde programma te ontmoedigen. Kritiek moet gegeven worden met de intentie het programma beter te maken in zijn huidige vorm.
The new rule is good.However, I noticed that the dutch rules weren't updated. You might want to change this:Quote from: the rules(Dutch)2: Negatief/onbeschoft/destructief commentaar op iemands project of programma gebaseerd op bestandsgrootte, aantal subprogramma's en programmeertaal/~bibliotheken, met de bedoeling de auteur van het genoemde programma te ontmoedigen. Kritiek moet gegeven worden met de intentie het programma beter te maken in zijn huidige vorm.By something like this:2: Negatief/onbeschoft/destructief commentaar op iemands project of programma gebaseerd op bestandsgrootte, aantal subprogramma's, programmeertaal/~bibliotheken of de manier waarop het programma geschreven is, met de bedoeling de auteur van het genoemde programma te ontmoedigen. Kritiek moet gegeven worden met de intentie het programma beter te maken in zijn huidige vorm.Just so new members who read the dutch rules also know of this.
2: Comentários negativos/destrutivos/mal-educados em direção ao projecto de um utilizador ou programa baseados no tamanho do programa, quantidade de sub-programas ou linguagem de programação/livrarias usada(as), com o objectivo de desencorajar o utilizador. Críticas aos projetos/programas devem ter como objetivo fazer com que o projeto dessa pessoa seja melhor na sua forma atual.
2: Comentários negativos/destrutivos/mal-educados em direção ao projecto de um utilizador ou programa baseados no tamanho do programa, quantidade de sub-programas ou linguagem de programação/livrarias usada(as) ou métodos de escrita de código, com o objetivo de desencorajar o utilizador. Críticas aos projetos/programas devem ter como objetivo fazer com que o projeto dessa pessoa seja melhor na sua forma atual.
2: Negative, unhöfliche sowie unkonstruktive Kommentare bezüglich dem Projekt oder Programm einer Person, die auf der Datei-Größe, Anzahl von Subrutinen oder der Programmiersprache bzw. der benutzten Bibliothek beruhen. Und nur dem Entmutigung des Autors dienen. Kritik sollte immer dazu da sein die Programme einer Person in ihrer momentanen Form zu verbessern.
2: Negative, unhöfliche sowie unkonstruktive Kommentare bezüglich dem Projekt oder Programm einer Person, die auf der Datei-Größe, Anzahl von Subrutinen, der Programmiersprache oder dem Schreibstil bzw. der benutzten Bibliothek beruhen und nur der Entmutigung des Autors dienen. Kritik sollte immer dazu da sein die Programme einer Person in ihrer momentanen Form zu verbessern.
I like this cause many people would consider my programming style very sloppy (think int integer1, integer2, integer3;) lack of comments, minimal use of standard libraries, pointer abuse, random inlined asm code, type cast abuse, and other hackish obfuscations. Maybe not the best way to code for most people but as long as I get stuff done and it works I see no problem.
Have either of you ever successfully understood your own code after not having seen it for long periods of time? Coding w/o comments might be fine just to get working code, but it does awful things to maintainability. (Of course, both of you have probably heard this before; note that this is meant to be constructive criticism, not anything negative, and that I'm not saying directly that you're doing it wrong. )