|
KISS -
1) Lots of small, primitive working components that perform a specific task and clip together?
2) Few large complex classes?
Which one?
[Edit: Typo - Simple = Complex in 2nd option]
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
You got something here! At a certain point, complexity can be moved around between "participants", but it remains in the project.
"clipping components together" can increase complexity by one (thinking on a logarithmic scale)
If your target is, however, still two or three orders of complexity away, you are in trouble. I think the idea is to plug together the next layer's "small, primitive classes" from the layer below. However, plugging components may give you the robustness of an application, but components have much higher requirements to be pluggable. At each layer, you spend more and more glue code to fit things together.
It helps to start with a "more skilled", higher level language (i.e. start at higher complexity already, so the gap gets smaller), or apply KISS to the project goals (but that's not always possible).
Hmmm... no solution, nope.
|
|
|
|
|
From my experience, combining the smallest atomic parts together to create another simple atomic part is simply part of good system design. I've encountered HUGE function classes which have masses of dependancies on other stuff and it's a complete nightmare to figure out.
At least with lots of small components you can black box at each level and the whole system becomes that much simpler to comprehend.
T
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
Complexity does not necessarily contradict the KISS principle. Many problems are complex, but the constituent parts to the solution should be as simple as possible to solve the problem.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
somestateinfo gives you literal strings for the names, so it's a replacement for:
enum
{
ST_State1 = 1,
ST_State2 = 2,
ST_State3 = 3,
ST_LAST
}
sometype stateinfo[] =
{
{ "ST_State1", 0, 0 },
{ "ST_State2", 0, 0 },
{ "ST_State2", 0, 0 },
}
If he'd used, say, #define makestate(NAME, NUM) { "ST_"#NAME,NUM,0},
you could derive a name-value mapping for enums. It could even remove a prefix from the enum constant.
The "inside a function" counts the values actually defined, which would be better derived from sizeof(stateinfo)/sizeof(stateinfo[0])
Not that I ever endorse such conding practices
But it's a not-to-unusual way around lack of reflection in C / C++.
|
|
|
|
|
I'm just trying to figure out how I'd do this.
I never liked having an enum and a separate string array that had to be kept in sync.
I learned some more about the "C preprocessor" today.
More reason to like C#
|
|
|
|
|
I think the best thing would be an Excel sheet (or similar) and a code generator that is included in the build process.
|
|
|
|
|
I'm now pondering storing the values in XML and using XSLT to create the h file.
XSLT: the new C Preprocessor
|
|
|
|
|
that'd be worthy of a fresh thread here in and of itself.
--
CleaKO The sad part about this instance is that none of the users ever said anything [about the problem].
Pete O`Hanlon Doesn't that just tell you everything you need to know about users?
|
|
|
|
|
Correct you are, but should I? Or should it go in, perhaps, the XML/XSL forum? Or an article?
Aw heck, here it is, you decide:
state.xml
<state Prefix="ST_" Type="sometype" >
<State1>0x01</State1>
<State2>0x02</State2>
<State3>0x03</State3>
</state>
state.xsl
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" >
<xsl:output omit-xml-declaration="yes" method="text"/>
<xsl:template match="/">
<xsl:for-each select="*">
typedef enum {
<xsl:for-each select="*">
<xsl:value-of select="../@Prefix"/><xsl:value-of select="name()"/>=<xsl:value-of select="."/>,
<xsl:if test="position()=last()"><xsl:value-of select="../@Prefix"/>LAST=<xsl:value-of select="last()"/></xsl:if>
</xsl:for-each>} <xsl:value-of select="name()"/>type ;
<xsl:value-of select="@Type"/><xsl:text> </xsl:text><xsl:value-of select="name()"/>info[] = {
<xsl:for-each select="*">
<xsl:if test="position()!=1">,</xsl:if>{"<xsl:value-of select="../@Prefix"/><xsl:value-of select="name()"/>",0,0}
</xsl:for-each>}
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>
result
typedef enum {
ST_State1=0x01,
ST_State2=0x02,
ST_State3=0x03,
ST_LAST=3} statetype ;
sometype stateinfo[] = {
{"ST_State1",0,0}
,{"ST_State2",0,0}
,{"ST_State3",0,0}
}
As mentioned elsewhere, the counting of the entries in part two is unnecessary, but notice that here I set the value of ST_LAST to the number of entries.
|
|
|
|
|
I call a WTF!
--
CleaKO The sad part about this instance is that none of the users ever said anything [about the problem].
Pete O`Hanlon Doesn't that just tell you everything you need to know about users?
|
|
|
|
|
What's your alternative of choice?
|
|
|
|
|
I actually wanted to do that as a project to "learn XML", but just the basics were such a bumpy ride that I contracted some kind of XML allergy.
So if you do: A R T I C L E !
|
|
|
|
|
Be careful what you ask for.
|
|
|
|
|
PIEBALDconsult wrote: Be careful what you ask for.
I believe this actually is a case where he wants to get what he wishes for..
|
|
|
|
|
(He's probably the only one.)
|
|
|
|
|
Yeah, maybe.
|
|
|
|
|
Wish granted, just submitted the article.
(Now waiting for the tomatoes to start flying.)
|
|
|
|
|
Waiting for it to appear...
|
|
|
|
|
This looks like "Security through obscurity" or the writer of this code wants to write such mess.
If this is the style of the writer he ist a danger for the company.
Greetings from Germany
|
|
|
|
|
I have a general R&D solution I use to fiddle and explore various technicalities in. I add little disposable projects here and there as I need to explore some CLR or language feature or something. I only have one project at a time configured to build, the one I'm busy on, so I don't get dependency problems etc.
So, I add a little WinForms project to test aspects of inheritence, and I hit F5 to run it, but this damn Assembly Search dialogue pops up, defaulted to a TestDriven.NET assembly. I check the key mapping for F5 and it's normal. I exit VS and start again, with the same damn Assembly Search dialogue invading my precious peace. I disable TestDriven.NET and on trying again I still get this hell spawn dialogue popping up.
Then I notice I have an AssemblySearch project in the solution, , and it's set as the Startup Project
I didn't expect it do do anything because it's excluded from the solution build, but, it wasn't building, just running.
|
|
|
|
|
That happens.
I discovered that same thing a while back, the thing that bothers me most is having to mark side projects (tests) to no build or vise-versa. It is irritating to have all subprojects rebuilt when I only want to rebuild the current one, especially if the current one is trying to test a piece of code that is causing an error in one of the other projects.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
I hired a programmer right out of school. Started him on a very simple project. I performed a tech review of the code and saw the following method call
private integer inc(integer int_i)
{
integer int_j=int_i+1;
return int_j;
}
He no longer works for the company.......
Moose Man
|
|
|
|
|
Look at the bright side, the code was easy to understand.
|
|
|
|
|
didn't he try to compile it before he gave you the code.... or better yet, Didn't the syntax highlighting of whatever the latest and greatest IDE you're using catch it... or if this is c++ why didn't he just go int_i++ its a lot faster then inc(int_i) (assuming he had his datatypes spelled right)
|
|
|
|