|
Helping people out in the forums is fine, in Q&A it is not IMO. They should have revamped the forums a little, rather than reinventing half of everything and omitting some essentials.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
Luc how can I join your club?
|
|
|
|
|
You already have!
|
|
|
|
|
16-MAY-2010: an attempt to remove smileys ended in popular uprising[^]
03-JUN-2010: deleted comment[^] confusion.
05-JUN-2010: abuse[^], abuse should be discouraged; it is partly due to formatting.
Nish agrees.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
modified on Thursday, June 10, 2010 10:39 PM
|
|
|
|
|
Thanks for keeping us informed. I was unaware of this move. You read the messages before you delete them all?
Thanks.
In Christ,
Aaron Laws
http://ProCure.com
|
|
|
|
|
This was started as an effort to summarize my doubts about the viability of Q&A, as separate parts of it got discussed early on. By no means it is complete; however I'm afraid most of the original 10 points are still very valid today.
Yes, I read what people answer to my messages, here as well as elsewhere; and I don't want this blog to become a Q&A discussion forum that grows without limits, so I included the warning that things would disappear. From time to time, I clean up and adapt/extend my summary view.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
Luc Pattyn wrote: others can modify text that I have published and signed my name to. IMO this is
unacceptable
Is this still unacceptable?
What if we made it so that for members with Bronze (or no) Authority, questions are able to be edited. For members Silver and above there could be a preference setting (both in your profile and in the "post a question" page that allowed you to decide whether to allow others to fix up any mistakes. Obviously if questions (and answers) were editable then versioning would have to be introduced.
Having changes marked in a different colour is fine when comparing versions, but needlessly distracting for a member simply looking to read and answer questions. They don't care who edited what - they just want the question to be as well-phrased as possible.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
In Q&A and forums I don't want others to modify my texts as that may well end up misrepresenting what I intended to say; and it would make me wonder why they changed things. So if selectable, I would switch it off for sure. And if not selectable, I would not even bother to participate, unless, maybe, under an alias if I were badly needing an answer to some problem.
I don't even like your editors touching my articles, I'd much prefer they teach me the rules of the site, and/or the English grammar rules I violated, or whatever applies, so I can fix it myself, learn from it, and avoid repeating the mistake. As is, all I can do is search for the changes and guess why they got applied, which takes longer and doesn't tell me much.
And everywhere, I might not even agree with the changes; in the end things would go back and forth till someone gave up. (I probably would not waste the time at all, and would prefer to have it all removed).
Things would be different for orphaned material. If an author has disappeared for quite a while, or does not react at all, then I would not mind someone with sufficient authority taking charge, provided such were represented quite clearly, as in "article by DEF (who took over the original work by ABC on some date)".
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
So is that a yes to "For members Silver and above there could be a preference setting (both in your profile and in the "post a question" page that allowed you to decide whether to allow others to fix up any mistakes"?
While I'd love to live in a utopia where all questions are prefectly phrased and formatted, and any mistakes can be quietly pointed out, knowing they will be fixed immediately by the author, that isn't reality. New posters, lazy posters, and posters who are not great at English, formatting, spelling, layout or just plain phrasing make it hard for others to help them, so allowing those who have the time and patience to help improve their questions is a valuable service.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
yes: if selectable, I would switch it off for sure.
Chris Maunder wrote: While I'd love to live in a utopia
maybe you should join the Borg. 
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
lpzyx buttons
LPattyn
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
Local announcement (Antwerp region): Lange Wapper? Neen!
modified on Saturday, October 17, 2009 12:21 AM
|
|
|
|
|
lpzyx button
LPattyn
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
Local announcement (Antwerp region): Lange Wapper? Neen!
modified on Saturday, October 17, 2009 12:21 AM
|
|
|
|
|
lpzyx button buttons
LPattyn
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
Local announcement (Antwerp region): Lange Wapper? Neen!
modified on Saturday, October 17, 2009 12:22 AM
|
|
|
|
|
1. PRE and CODE blocks have syntax coloring, the language is C++ by default, but can be changed by adding a lang='text' or lang='cs' to the opening tag.
2. a lot of HTML commands also work inside a PRE block
3. Background colors:
PRE blocks can get a different BG color by adding style='background-color:#DDDDFF' as in
#DDDDFF
#DDFFDD
#FFDDDD
#DDFFFF
#FFDDFF
#FFFFDD
all text, inside or outside a PRE block, can get another BG or FG color by putting it into a <span class='highlight'>yellow</span> or <span class='emphasis'>red</span>
text yellow text red text
Luc Pattyn
Local announcement (Antwerp region): Lange Wapper? Neen!
|
|
|
|
|
Language is C# by default.
|
|
|
|
|
Nope. Here is a test, same code block, three different PRE lang options:
without lang
abstract auto checked class const delegate enum explicit extern fixed friend
keywords in C# not in C++: checked fixed
keywords in C++ and not in C#: friend
with lang='C++'
abstract auto checked class const delegate enum explicit extern fixed friend
keywords in C# not in C++: checked fixed
keywords in C++ and not in C#: friend
with lang='cs'
abstract auto checked class const delegate enum explicit extern fixed friend
keywords in C# not in C++: checked fixed
keywords in C++ and not in C#: friend
Furthermore it is my opinion the default should be:
- the relevant language in PRE tags in language-oriented forums
- 'text' elsewhere (including all CODE tags)
Luc Pattyn
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
Local announcement (Antwerp region): Lange Wapper? Neen!
modified on Thursday, October 15, 2009 8:21 PM
|
|
|
|
|
I am not sure. Here[^] is what Chris says.
|
|
|
|
|
1
2 public const double PI1 = 3.14159262;
3 public const double PI2 = 3.14159262;
4 aaa bbb ccc
5 ddd
6 eee fff
10 bold
11 italic
12 underline
13 string s1="stringLiteral1";
14 yellow
15 red
16
17 public const double PI1 = 3.14159262;
18 public const double PI2 = 3.14159262;
19 aaa bbb ccc
20 ddd
21 eee fff
25 bold
26 italic
27 underline
28 string s1="stringLiteral1";
29 yellow
30 red
31
32 public const double PI1 = 3.14159262;
33 public const double PI2 = 3.14159262;
34 aaa bbb ccc
35 ddd
36 eee fff
40 bold
41 italic
42 underline
43 string s1="stringLiteral1";
44 yellow
45 red
13-DEC-2009: All works well on forum message, except for linecount.
|
|
|
|
|
Luc Pattyn
Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.
Local announcement (Antwerp region): Lange Wapper? Neen!
Luc Pattyn
Local announcement (Antwerp region): Lange Wapper? Neen!
|
|
|
|
|
Het viaductengedrocht, de naam brug totaal onwaardig;
de aansluiting in Deurne/Merksem, 18 baanvakken waanzin;
het lawaai en de stank;
de schabouwelijke communicatie;
de ongehoorde verspilling;
het ongefundeerde financiele plaatje;
en na 10 jaar zero resultaat.
Nee dank u. Van die boer geen eieren. Nu niet, nooit niet.
Luc Pattyn
Local announcement (Antwerp region): Lange Wapper? Neen!
modified on Wednesday, September 30, 2009 5:35 PM
|
|
|
|
|
|
Hi,
when you set out to learn a new technology (language, framework, protocol, whatever), I normally recommend reading a book about it. That is a physical book, not an article, not an e-book.
So my advice consists of a sequence of actions:
1. go to a decent book store, so you can see and compare a number of relevant books;
2. browse through the available books, trying to figure out which ones you like and which ones you don't like; that will be a matter of personal taste, and strongly depends on your prior knowledge, your earlier experience with similar technologies, your need for elaborated examples, your want for exercises, etc. That is why I typically do not recommend specific books: what looks great to me, may be too simple, too complex, or just not right for you; and vice versa.
3. I recommend buying at least one introductory book or tutorial; that is something explaining the philosophy and providing the essential knowledge without diving right away into all the gory details.
4. And I suggest to also consider buying a reference book, something that explains all the gory details, so you can look up anything you need as far as syntax and semantics go. For a reference book it is essential to include a decent index; just read one page, and any new terms you encounter must be present in the index. If they don't, don't consider buying the reference book. You may argue a reference book isn't essential as all the information probably is available on the web anyway; that is probably correct, however you will become more familiar with a book you own, than you would with different answers from different people you would get when searching the web regularly. Anyway, IMO there is no alternative for buying a tutorial book.
5. It isn't enough to own a good book. The hardest and most rewarding part is studying its content. So set out to read it from front cover to back cover; on a first read you may decide to skip some chapters, if and only if they are specializing in a topic you don't need right away (say database access when you plan on creating a game).
6. Start using the new technology, experiment as much as you want. Make sure to browse the reference manual and/or the documentation (MSDN or other) anytime you feel a need to. And read around the specific topic of interest, the page before and after the current one probably are relevant too.
7. After some period, say one year, study the tutorial again; read again everything you have read before, and skip fewer or none of the chapters you did skip earlier. You'll be surprised by how much you did not discover (or plainly forgot) in the first pass.
The advantage of a book is it attempts to teach you a lot, in a logical order and using a consistent language, explaining and illustrating the rationale and the strong points; as such you will gather much more information than you could by just experimenting at random, and/or asking questions on some forum. Working your way through a book really is the most efficient way to systematically acquire new knowledge in a short period of time.
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
modified on Tuesday, July 14, 2009 11:03 PM
|
|
|
|
|
|
My more general statement is: "you can't catch all in one go", and it applies to discovering bugs as well: a thorough code analysis or product test may uncover 90% of all existing problems, it will not uncover 100% of them; that is why one should try and keep the initial number of problems low, as some fraction of them will slip through whatever the numbers are".
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
Probably better piece of advice I've received this year at least.
cheers.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
Now with 24% more Twitter
![Badger | [badger,badger,badger,badger...]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/badger.gif)
![Jig | [Dance]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/jig.gif)
