This forum is for any and all questions for Code Project Article Writing:
Have a question about writing an article?
Having trouble posting?
Blog aggregation not working?
Not sure about your article topic?
Is your article still pending?
Is there a crazy formatting problem in your article?
Not sure how to update your article?
Having problems with the submission wizard?
Need help making a change to an existing article?
As a basic overview CodeProject articles have a certain layout to follow, so that users can learn the most from them. Each article attempts to answer the following questions: What problem does this solution solve? How does this help someone else? How does the code actually work? What is going on inside the code snippets?
Here is a submission from a first time author who did a terrific job, just to give you a basic overview of what a beginner article might look like: Avoiding InvokeRequired[^]
I always want to give an nice article. But my poor English and my poor Writing Flow. Always my article are goes into the tips section . Everybody asks the explanation about the article. But I clearly explained with my knowledge.
I guess the problem is my poor English.
I believe I'd definitely improve my skills in codeproject.com
I want the answers for following questions. Kindly Answer me.
1) How to improve my English?
2) How to Improve my Writing skills? Need Some Sample Articles? (Easily Understandable).
First of all, please let me congratulate you on the fact that you are writing for CodeProject. It's truly a wonderful thing choosing to share knowledge with others. Now, if you are wondering why someone says it should be a tip/trick and not an article, it's normally because of one of these things:
The article is primarily a code dump. There's very little explanation of the code.
The article is short. It shows what you are doing but doesn't explain why you are doing it, what made you choose to implement it that way, what the alternatives were that you rejected and so on.
The article is short - even with a full explanation of why you chose to do it that way and so on, the actual code is still only two or three lines long.
If you want to see what constitutes an article, please go and read articles by Nish Sivakumar, Marc Clifton, Sacha Barber, Daniel Vaughan, Paulo Zemek and many other wonderful authors. The thing you will see in all of their work is attention to detail and the amount of thought they put into crafting their articles.
As far as your English goes, don't worry too much about it. When you finish writing an article, don't submit it - leave it in composing status and email Sean Ewington to ask if a CodeProject mentor can take a look at it. The mentors will generally help guide you through the process of getting your article published. They will tell you what needs to be changed and why.
I published an article recently (see here[^]). But it seems that it was not set up correctly:
1) The code is not browsable (not commited into the git repository). Am I supposed to do it myself? If so how?
2) The popularity of the article is 0.00, which is likely not true since it has some audience and downloads.
Is this article is only half living somehow?
Hope somebody can help me. Just noticed that the last editor of this article Facade to disparate databases[^] has included a few extraneous XML tags in some C# code. The added tag is </integratedfaultcontracts> and is in the 'Take a License', 'Update a Use' and 'Delete a Use' paragraphs, last item after the closing brace.
Please could someone let me know how I can fix this? When I try to update the article I don't see the version with those changes in it.
I've done it again. I wrote an article, but apparently I used too few words. Question to the moderators and reviewers, since when quantity trumpets quality? Things that used to take us hundreds of lines of code, became one-liners, which do not require elaborate explanation or walk-through. So why are the reviewers stuck in the mindset that more words is better?
What goes on in that one line though? Just because something can be reduced to one line doesn't mean that we don't want to know why you are using that one line? What decisions you took in deciding that one line fits the problem domain? What are the edge cases or compromises that we have to consider?
That's what we want to know, and you can't cover that type of thing in a few lines in an article. It's not just the how, it's the what and why as well.
It doesn't, but sometimes a lack of quantity means there is very little quality. Don't forget that not everyone who reads the article is at the same knowledge level. Some people will be absolute beginners and will need all those extra words just to understand what you are trying to teach them. Those who have a better background will be able to skim read to the parts that they need.