Developer News Style Guide
This guide is for anyone writing for w3Develops: tutorials, project write-ups, community updates and news posts. It keeps our articles clear, accurate and welcoming, whoever writes them.
In short: write for a beginner, show your sources, and test your code.
Last updated: November 10, 2026
What we publish
In short: Useful writing for developers at every level.
- Tutorials that walk through building or fixing something, step by step.
- Project write-ups from study groups, group projects and hackathons: what you built and what you learned.
- Community updates about groups, book clubs, meetups and competitions on w3Develops.
- News posts that sum up what happened in tech and why it matters to developers.
We don't publish ads, press releases, paid placements, or anything you don't have the right to share.
Voice
In short: Plain, friendly and direct, like explaining something to a classmate.
- Use short sentences and everyday words. Many readers are learning English as well as code.
- Talk to the reader as “you”, and write in the active voice: “Run the tests”, not “The tests should be run”.
- Explain a technical term the first time you use it, or link to a good explanation.
- Skip words like “simply”, “just”, “obviously” and “easy”. If a step is easy, the reader will notice.
- No hype or clickbait. A headline should tell the reader what they'll get, not tease it.
Structure
In short: Say what the article is about straight away, then make it easy to scan.
- Title: sentence case, under about 70 characters, and specific: “Build a to-do app with React and Firebase”.
- Opening: two or three sentences on what the reader will learn or build, and what they need to know first.
- Headings for each step or idea, so readers can jump to the part they need.
- Short paragraphs, and lists for steps or options.
- Ending: sum up, and point to a next step, like a related article, the full code, or a study group on the topic.
Code
In short: Every code sample should run as written.
- Test every sample before you publish, and say which versions you used, like Node 20 or React 19.
- Put code in code blocks marked with the language, and keep each block short enough to follow.
- Explain what each block does, especially lines a beginner might copy without understanding.
- Use
inline codefor file names, commands, functions and variables. - Never include real passwords, API keys or tokens. Use placeholders like
YOUR_API_KEY. - Link to the full code on GitHub when a project is too big for the article.
Accuracy and sources
In short: Link what you rely on, and write in your own words.
- Link to the original source for facts, numbers and news: the official docs, announcement or study, not a post about it.
- Summarize in your own words. Quote only a sentence or two, in quotation marks, with credit and a link.
- Don't copy articles, tutorials or docs, even with credit.
- Give dates for anything that changes, like prices, versions or release plans.
- If you find a mistake after publishing, fix it and add a short note at the end saying what changed.
Images
In short: Use images you have the right to use, and describe them.
- Use your own screenshots and images, or ones with a license that allows reuse, and credit the source.
- Give every image alt text that says what it shows, for readers using screen readers.
- Check screenshots for private details, like email addresses, names or open tabs, and blur them.
Writing with AI
In short: AI can help, but you're responsible for every word.
You may use AI tools to help draft, edit or check your writing. Check every fact, link and code sample yourself, and say at the end of the article if AI helped write it. w3Develops' own scheduled posts are labeled when AI helped write them.
Words, names and numbers
In short: Write for a global audience.
- Spell names the way their owners do: JavaScript, GitHub, Node.js, w3Develops.
- Write dates as “November 10, 2026” and give times in UTC, so readers in every time zone can convert them.
- Use inclusive language: “they” for an unknown person, “allowlist” and “main branch”, and no jokes at any group's expense.
- Spell out an abbreviation the first time, like “continuous integration (CI)”.
Before you submit
In short: A quick checklist.
- The title and opening say what the reader gets.
- Every code sample runs, and every link works.
- Sources are linked, and nothing is copied.
- Images have alt text and no private details.
- You've read it out loud once. Awkward sentences are easy to hear.
Want to write for w3Develops? Share your idea in our Discord. Everyone taking part follows our Code of Conduct.