Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Garyhlucas on March 17, 2021, 10:43:02 AM
-
In the Documentation Editor the Spacebar produces an underline character when typing in the Element name. However when adding a new Element the Spacebar produces a space which is then generates an error message. I think they should both work the same.
Second small annoyance I mentioned a long time ago. When copying an element the editor adds an underline at the beginning of an Element name and also increments the end of the element. This then requires you to edit both ends of the new Element which effectively defeats the time savings you get from copying. Just incrementing the end of the Element would be so nice. The first Element could be Alarm_, the second would then be Alarm_2, Alarm_3 and so on.
-
In the Documentation Editor the Spacebar produces an underline character when typing in the Element name. However when adding a new Element the Spacebar produces a space which is then generates an error message. I think they should both work the same.
Second small annoyance I mentioned a long time ago. When copying an element the editor adds an underline at the beginning of an Element name and also increments the end of the element. This then requires you to edit both ends of the new Element which effectively defeats the time savings you get from copying. Just incrementing the end of the Element would be so nice. The first Element could be Alarm_, the second would then be Alarm_2, Alarm_3 and so on.
The spacebar to _ was a hack to help folks who kept trying to use spaces, which are unsupported. Yes, it should be that way everywhere, but there is a lot of "everywhere".
That said, with only 16 characters available, I would personally never waste them using underscores. Camel case is more efficient and just as readable.
-
Oh yeah, the other day i was meaning to check back in on the 16-character limit. I know there were plans to increase the limit, is there an ETA for that?
-
Oh yeah, the other day i was meaning to check back in on the 16-character limit. I know there were plans to increase the limit, is there an ETA for that?
We're doing some work on the display code to facilitate arbitrary lengths. We'll see how that goes before we dig deeper.
-
We're doing some work on the display code to facilitate arbitrary lengths. We'll see how that goes before we dig deeper.
Cool, thank you for the update.
-
Can you explain what camel case is?
-
ThisIsCamelCase
(humpy on top like a camel, thought not long-necked like a goose) ;D
-
HeatPump or heatPump vs Heat_Pump or heat_Pump. No underscore to save character space.
-
All lower case with underscores was commonly used back in the C programming days, but most use camel case in C++ or Java (my_variable_name vs MyVariableName).
-
Thanks guys!
-
I don't write programs for me to understand, I write them for others to understand so I use the underscores to make it very readable. However I get your point about it, I liked the space bar handling the job.
-
Camel Case is great until it is imported to Cmore, "ThisIsCamelCase" becomes "THISISCAMELCASE". Please increase the character limit because it is impossible to get AD to make a desired change to Cmore.
-
I don't write programs for me to understand, I write them for others to understand so I use the underscores to make it very readable. However I get your point about it, I liked the space bar handling the job.
That content confounds me. It sounds as if camel case would be OK if you were wilting the comments for yourself, but others need underscores, but I can't imagine that's what you're saying.
-
That content confounds me. It sounds as if camel case would be OK if you were wilting the comments for yourself, but others need underscores, but I can't imagine that's what you're saying.
Clarity is all about what you are used to seeing. There isn't a right or a wrong. I wasn't trying to start a holy war of programming standards, only offering an approach that offers a slight bit more efficiency until we can power through the changes required to render the discussion moot.
-
Agreed. I'm not feeling particularly religious about the camel case vs. underscore thing, just couldn't follow the logic in his post and was hoping for clarification.
-
I don't write programs for me to understand, I write them for others to understand so I use the underscores to make it very readable. However I get your point about it, I liked the space bar handling the job.
That content confounds me. It sounds as if camel case would be OK if you were wilting the comments for yourself, but others need underscores, but I can't imagine that's what you're saying.
I think he is saying that to the "untrained eye", underscoring is (slightly) easier to read than CamelCase.
Myself, I don't mid CamelCase, but where it gets me into trouble is if I start using acronyms in the name already to save space, all of a sudden it reads ABCCamelCaseBit1, and then for readability it needs to become ABC_CamelCaseBit1, and that is 17 characters. Also, I end up using characters to denote if something is a Timer or a Stage, etc to differentiate it from the pushbutton or output, etc.
In short, I'm patiently waiting for the code to allow longer nicknames. But I will say I'd much rather have features such as the new Modbus Scanner. And the continual improvements/bug fixes that are openly acknowledged, fixed, and time-lined. Not too many software/tech companies are that open about their bugs.
-
Yeah, Host is awesome that way. What I'd like to see, if it can be done without too big a scan time hit, is a really big ask: more places where you can use arbitrary expressions that get parsed at runtime. :)
-
The engine can actually do the math thing already. The issue is DmD...tons of complications to entering, statusing, storing, and decompiling.
Our next big language improvement will probably be a C-meets-Structured-Text code block, which will free us from the shackles of decompilation.
-
Our next big language improvement will probably be a C-meets-Structured-Text code block, which will free us from the shackles of decompilation.
As much as I'd love wider acceptance of expressions, I'd like to have that first even more!
BTW, if the engine can handle parsing expressions in other places, have you profiled the functionality any, and if so, how big an impact does it have on scan time?
-
Same as MATH box. Engine doesn't parse any of it, just runs it.