<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	xmlns:georss="http://www.georss.org/georss"
	xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#"
	
	>
<channel>
	<title>
	Comments on: What 70 people came up with on expressive code	</title>
	<atom:link href="https://www.fluentcpp.com/2017/02/06/what-70-people-came-up-with-on-expressive-code/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.fluentcpp.com/2017/02/06/what-70-people-came-up-with-on-expressive-code/</link>
	<description>Jonathan Boccara&#039;s blog</description>
	<lastBuildDate>Mon, 03 Aug 2020 10:46:22 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.5.4</generator>
	<item>
		<title>
		By: Aurelien		</title>
		<link>https://www.fluentcpp.com/2017/02/06/what-70-people-came-up-with-on-expressive-code/#comment-146</link>

		<dc:creator><![CDATA[Aurelien]]></dc:creator>
		<pubDate>Fri, 10 Mar 2017 09:44:00 +0000</pubDate>
		<guid isPermaLink="false">https://www.fluentcpp.com/?p=665#comment-146</guid>

					<description><![CDATA[&lt;blockquote&gt;[pattern matching] I’m not sure how this can be emulated in C++ as of today.&lt;/blockquote&gt;

You can have a look at this library developed by renowned people in the C++ community:
https://github.com/solodon4/Mach7

Regarding the use of comments, ideally they should not be required to understand what a new code written from scratch does. But they are really useful to explain the constraints, quote issues/RFC/papers, and &lt;b&gt;tell what the code doesn&#039;t do and why&lt;/b&gt;.

Any complex / legacy system tend to have a growing number of comments over time and these comments are precious, sometimes more than the code itself, because they contain the knowledge that was painfully acquired over time. Just have a look at WebKit, the Linux Kernel, LLVM, etc...]]></description>
			<content:encoded><![CDATA[<blockquote><p>[pattern matching] I’m not sure how this can be emulated in C++ as of today.</p></blockquote>
<p>You can have a look at this library developed by renowned people in the C++ community:<br />
<a href="https://github.com/solodon4/Mach7" rel="nofollow ugc">https://github.com/solodon4/Mach7</a></p>
<p>Regarding the use of comments, ideally they should not be required to understand what a new code written from scratch does. But they are really useful to explain the constraints, quote issues/RFC/papers, and <b>tell what the code doesn&#8217;t do and why</b>.</p>
<p>Any complex / legacy system tend to have a growing number of comments over time and these comments are precious, sometimes more than the code itself, because they contain the knowledge that was painfully acquired over time. Just have a look at WebKit, the Linux Kernel, LLVM, etc&#8230;</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Jonathan		</title>
		<link>https://www.fluentcpp.com/2017/02/06/what-70-people-came-up-with-on-expressive-code/#comment-89</link>

		<dc:creator><![CDATA[Jonathan]]></dc:creator>
		<pubDate>Thu, 09 Feb 2017 04:03:00 +0000</pubDate>
		<guid isPermaLink="false">https://www.fluentcpp.com/?p=665#comment-89</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://www.fluentcpp.com/2017/02/06/what-70-people-came-up-with-on-expressive-code/#comment-88&quot;&gt;FredTingaud&lt;/a&gt;.

My point about automatic tools is not to generated automatic documentation like your example your are mentionning but more to generate template for doxygen (ex : /brief ...) and collapse/expand/coloring to avoid noise during code review (agree with you I have seen also &quot;iProID : the id of the Pro&quot; is just a noise)
In my experience if you ask a dev to add manually comments compatible with doxygen + update doc as soon as we change the prototype without any tools you have bugs in doxygen and doc not in line with code.
But in case of very sensitive api dispatch among hundreds of client we need tools to provide information to client but My point of view is comments into the code is too painful due to lack of tooks
]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://www.fluentcpp.com/2017/02/06/what-70-people-came-up-with-on-expressive-code/#comment-88">FredTingaud</a>.</p>
<p>My point about automatic tools is not to generated automatic documentation like your example your are mentionning but more to generate template for doxygen (ex : /brief &#8230;) and collapse/expand/coloring to avoid noise during code review (agree with you I have seen also &#8220;iProID : the id of the Pro&#8221; is just a noise)<br />
In my experience if you ask a dev to add manually comments compatible with doxygen + update doc as soon as we change the prototype without any tools you have bugs in doxygen and doc not in line with code.<br />
But in case of very sensitive api dispatch among hundreds of client we need tools to provide information to client but My point of view is comments into the code is too painful due to lack of tooks</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: FredTingaud		</title>
		<link>https://www.fluentcpp.com/2017/02/06/what-70-people-came-up-with-on-expressive-code/#comment-88</link>

		<dc:creator><![CDATA[FredTingaud]]></dc:creator>
		<pubDate>Wed, 08 Feb 2017 23:17:00 +0000</pubDate>
		<guid isPermaLink="false">https://www.fluentcpp.com/?p=665#comment-88</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://www.fluentcpp.com/2017/02/06/what-70-people-came-up-with-on-expressive-code/#comment-87&quot;&gt;Jonathan&lt;/a&gt;.

I would say it depends on what kind of API you have.
If you have a small API, with your clients including your headers in their code, they will probably read the documentation through their IDE. In which case, it will mainly be read as raw text and nice formatting will be in the way. Some minimalist Doxygen or just raw comments might be a good solution.
For big C++ APIs, I think more advanced Doxygen formatting and upload on the web is the norm, but I might be missing some recent cool tools.
For REST APIs, I hear lot of good things about Swagger.
I don&#039;t really agree with your need for a tool generating documentation automatically. Automatic documentation generation is doomed to be pure noise, in my opinion. I have seen tools documenting &quot;getValueAt(int i)&quot; with &quot;get the value at i&quot;, but it is already in the method&#039;s name. The documentation that interests me is what happens if i is negative or bigger than the number of values and only the implementer can write that.]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://www.fluentcpp.com/2017/02/06/what-70-people-came-up-with-on-expressive-code/#comment-87">Jonathan</a>.</p>
<p>I would say it depends on what kind of API you have.<br />
If you have a small API, with your clients including your headers in their code, they will probably read the documentation through their IDE. In which case, it will mainly be read as raw text and nice formatting will be in the way. Some minimalist Doxygen or just raw comments might be a good solution.<br />
For big C++ APIs, I think more advanced Doxygen formatting and upload on the web is the norm, but I might be missing some recent cool tools.<br />
For REST APIs, I hear lot of good things about Swagger.<br />
I don&#8217;t really agree with your need for a tool generating documentation automatically. Automatic documentation generation is doomed to be pure noise, in my opinion. I have seen tools documenting &#8220;getValueAt(int i)&#8221; with &#8220;get the value at i&#8221;, but it is already in the method&#8217;s name. The documentation that interests me is what happens if i is negative or bigger than the number of values and only the implementer can write that.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Jonathan		</title>
		<link>https://www.fluentcpp.com/2017/02/06/what-70-people-came-up-with-on-expressive-code/#comment-87</link>

		<dc:creator><![CDATA[Jonathan]]></dc:creator>
		<pubDate>Tue, 07 Feb 2017 21:38:00 +0000</pubDate>
		<guid isPermaLink="false">https://www.fluentcpp.com/?p=665#comment-87</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://www.fluentcpp.com/2017/02/06/what-70-people-came-up-with-on-expressive-code/#comment-86&quot;&gt;FredTingaud&lt;/a&gt;.

Indeed fred it is true for a client API
But after to make the choice of documentation comes the choice of tools:
Which tools to use ? Doxygen seems to be the most common one but the generated doc has not the same quality as Sphinx for example in python
Even if you customize well Doxygen you need a lot of plugin to generate doc in your code :
1) you need to have a tools that expand/collapse comments for code review
2) you need to have a way to generate automatically template for doxygen and modify automatically the code when you modify the prototype
Etc/etc
So I do not find any solution generator and tools that has the same kind of level that Sphinx in python for example
At  the end due to lack of complete solution about code documentation in C++ no one maintain the documentation
A wiki page I think is more adapted even for client API like a Rest service]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://www.fluentcpp.com/2017/02/06/what-70-people-came-up-with-on-expressive-code/#comment-86">FredTingaud</a>.</p>
<p>Indeed fred it is true for a client API<br />
But after to make the choice of documentation comes the choice of tools:<br />
Which tools to use ? Doxygen seems to be the most common one but the generated doc has not the same quality as Sphinx for example in python<br />
Even if you customize well Doxygen you need a lot of plugin to generate doc in your code :<br />
1) you need to have a tools that expand/collapse comments for code review<br />
2) you need to have a way to generate automatically template for doxygen and modify automatically the code when you modify the prototype<br />
Etc/etc<br />
So I do not find any solution generator and tools that has the same kind of level that Sphinx in python for example<br />
At  the end due to lack of complete solution about code documentation in C++ no one maintain the documentation<br />
A wiki page I think is more adapted even for client API like a Rest service</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: FredTingaud		</title>
		<link>https://www.fluentcpp.com/2017/02/06/what-70-people-came-up-with-on-expressive-code/#comment-86</link>

		<dc:creator><![CDATA[FredTingaud]]></dc:creator>
		<pubDate>Tue, 07 Feb 2017 14:53:00 +0000</pubDate>
		<guid isPermaLink="false">https://www.fluentcpp.com/?p=665#comment-86</guid>

					<description><![CDATA[Although I appreciate &quot;Clean Code&quot;, I think the stance on documentation is simplistic and wrong, for an API.
There is enough to say to fill a talk or a blog post (and I intend to do both in the future :) ) but to summarize, even if you are in a specific case where your API user has access to the code and knows your programming language (so no REST service, no closed-source compiled library, etc.) ; even if the user wants to spend 10 minutes reading code instead of a few seconds to read the documentation of the API, what they will read is not what your method does, but how what your method does is implemented at the moment they read it.
Undocumented API leak their implementation into the user code.
Good luck changing an implementation detail when you have hundred or thousand of users counting on it because they had no way to know whether it was part of the API or an implementation detail.]]></description>
			<content:encoded><![CDATA[<p>Although I appreciate &#8220;Clean Code&#8221;, I think the stance on documentation is simplistic and wrong, for an API.<br />
There is enough to say to fill a talk or a blog post (and I intend to do both in the future 🙂 ) but to summarize, even if you are in a specific case where your API user has access to the code and knows your programming language (so no REST service, no closed-source compiled library, etc.) ; even if the user wants to spend 10 minutes reading code instead of a few seconds to read the documentation of the API, what they will read is not what your method does, but how what your method does is implemented at the moment they read it.<br />
Undocumented API leak their implementation into the user code.<br />
Good luck changing an implementation detail when you have hundred or thousand of users counting on it because they had no way to know whether it was part of the API or an implementation detail.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Jonathan Boccara		</title>
		<link>https://www.fluentcpp.com/2017/02/06/what-70-people-came-up-with-on-expressive-code/#comment-85</link>

		<dc:creator><![CDATA[Jonathan Boccara]]></dc:creator>
		<pubDate>Tue, 07 Feb 2017 11:02:00 +0000</pubDate>
		<guid isPermaLink="false">https://www.fluentcpp.com/?p=665#comment-85</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://www.fluentcpp.com/2017/02/06/what-70-people-came-up-with-on-expressive-code/#comment-84&quot;&gt;Jonathan&lt;/a&gt;.

Thanks for sharing Jonathan - and glad you found the post useful!]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://www.fluentcpp.com/2017/02/06/what-70-people-came-up-with-on-expressive-code/#comment-84">Jonathan</a>.</p>
<p>Thanks for sharing Jonathan &#8211; and glad you found the post useful!</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Jonathan		</title>
		<link>https://www.fluentcpp.com/2017/02/06/what-70-people-came-up-with-on-expressive-code/#comment-84</link>

		<dc:creator><![CDATA[Jonathan]]></dc:creator>
		<pubDate>Tue, 07 Feb 2017 08:03:00 +0000</pubDate>
		<guid isPermaLink="false">https://www.fluentcpp.com/?p=665#comment-84</guid>

					<description><![CDATA[Thanks for this feedback it is very interesting
I search for a long time a feedback about how to document a library and I am in line with the conclusion
If we write expressive code + make unit test the documentation is useless. However if you need to document a choice of design or a principle to respect a wiki page is more adapted. Same thing for mathematical approximation in function, for example if we make a certain limited development of a function you add the mathematical documentation in wiki or a pdf]]></description>
			<content:encoded><![CDATA[<p>Thanks for this feedback it is very interesting<br />
I search for a long time a feedback about how to document a library and I am in line with the conclusion<br />
If we write expressive code + make unit test the documentation is useless. However if you need to document a choice of design or a principle to respect a wiki page is more adapted. Same thing for mathematical approximation in function, for example if we make a certain limited development of a function you add the mathematical documentation in wiki or a pdf</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
