Omnimaga
Omnimaga => News => Topic started by: Hot_Dog on September 12, 2011, 06:41:58 pm
-
We've updated rule #2 of what constitutes inappropriate content and actions on our website and/or IRC:
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.
Perhaps some people like to write code and ask other people to optimize it for them. Other people may enjoy write their own code and take all the credit for themselves, without having any help from anyone despite people begging to help. Still others might like to write a program by taking portions of everyone's code from Axe and such, without using any code of their own (crediting the people, of course). Whatever the case, discouraging this kind of thing is as bad as flaming about what programming language to use. So we ask that if someone wants to code their own way, let them do so.
On a related note, we at Omnimaga do support friendly methods of encouraging people to "take it to the next level." If someone likes to write code without any help, perhaps we could encourage them to ask for help at least once. Or if someone likes to code by using code (with permission) from everyone else, we could encourage writing at least one routine.
-
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.
-
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.
Agreed, we're just trying to make sure that people don't let their opinion interfere with people trying to learn/have fun or those wanting to help said people. It happened before with programming languages used, amonst other things. In all these cases and more, voicing an opinion is one thing, but trying to enforce it is another.
-
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.
-
As long as we can still make recommendations, this is a great rule! I hope less people negatively criticize other people's code around here now :)
-
I like this rule because many times people have a good reason behind things they do, while other people might not understand why.
For example, I do stuff different than other people, simply because my computer isn't the most powerful one. It makes my life more easy doing it my way, rather than the other way :)
-
The new rule is good.
However, I noticed that the dutch rules weren't updated. You might want to change this:
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.
-
The new rule is good.
However, I noticed that the dutch rules weren't updated. You might want to change this:
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.
Why the dutch rules weren't updated is probably because non of us admins speak dutch :P
-
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.
There you go, updated Portuguese rules. Please, one of administrators, update them ;)
-
German update ;)
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 think the rules update is fine, but on the Register page, the entire rule section there should be replaced with links (maybe bolded) to respective languages on the other rule pages, because there we see dutch, french and english rules on one single page in the agreement section and it might be looking intimidating for some new members, even though it's just that they're translated in 3 languages there.
It would also prevent you from having to update an extra section of the site, which sometimes gets deleted during SMF upgrades anyway.
EDIT: SOmething like this:
Choose username:
Used only for identification by SMF.
Email:
This must be a valid email address. Hide email address from public?
Choose password:
Verify password:
Please type OMNIMAGA in the field. (spambot protection):
2+2? (spam protection too, awnser is 4 obviously lol):
Before registering, you must agree with our terms and conditions, available through the links below:
English (http://www.omnimaga.org/index.php?action=ezportal;sa=page;p=2) | Français (http://www.omnimaga.org/index.php?action=ezportal;sa=page;p=11) | Nederlands (http://www.omnimaga.org/index.php?action=ezportal;sa=page;p=10) | Deutsch (http://www.omnimaga.org/index.php?action=ezportal;sa=page;p=22) | Português (http://www.omnimaga.org/index.php?action=ezportal;sa=page;p=23)
I agree.
Register
The links should preferably open in a new window.
-
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.
Besides the frequent inline assembly, my C code sounds generally the same as yours :P no comments (they're just annoyances), everything optimized at the cost of readability, tons of random typecasts, etc.
-
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. :))
-
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. :))
indeed, and unless I comment every other line the comments are counter-productive to understanding the code again :P I actually process uncommented code better for some reason. Plus, I make up for comments with descriptive names and such, so heh :)
-
Personally I don't comment much. Normally I just make one comment about about 20 lines of code, and I say what they do as brief as possible. This being said, I also try and record every variable and its use on a sheet of paper beside me as I'm coding.
-
Names help indeed. With modern languages comments are less necessary since it's often apparent what the code does. :) The extreme version of the maintainability problem is not knowing why some complex/heavily optimized assembly code that you wrote is buggy (which has happened to me, hence my caution <_<)
-
To be frank, this new rule was kinda existent since 2008, but I never really made it clear nor did not need to enforce it very much. People should code the way that suits them best. Some people learn better from modifying people code, like me. In fact this is how I learned how to make tunnel or snake clones. One snake clone used matrices and taught me how to use matrices.
Afterward I just wrote my own code. If I optimize a program to death then decide to have someone check if it's as perfectly optimized as I thought, then I want the person to tell me what I did wrong if he changes stuff, so I know the next time.
Just make sure that if you voice your views on a coding method that you do it with respect, without imposing your view on others.