@JohnMMoore, I've heard it said that poor documentaion, especially code with little or no comments, is done for job protection. The designer wants to be the only person in the company who knows how the thing works. It's all about unique knowledge.
I don't like dots. I think that comes from my distant past when photocopiers were a bit "muddy" and a dot and a cross would look very similar. Fot that reason I use a half-moon "jump" where wires cross. However this is when I do my own (usually simple) schematics by hand or with MS Paint (luddite, aren't I?) With CAD programs you pretty much have to take what you get it seems, and the drawing style would hardly be a game changer....
Here, here! In the life of a schematic the engineer spends about 1% of his/her time with it. The rest of the time someone else has to read it and try and understand how the design works - and they usually have less education. It is CRITCAL that the development engineer take some time to make a clean schematic. It also goes a long way in helping the layout guy understand signal flow and layout.
I have to laugh sometimes at the way some schematics are done because it is usually a reflection of the way the development engineer thinks. If the schematic is a mess, the engineer doesn't usually think clearly or make clear decisions.
The main reason to take time to create a 'clean' schematic is that it is more than a graphical netlist. It is both the design and the design's documentation. It's likely someone else will look at it, and the kind thing to do is make it easy for everyone else to quickly understand the designer's intent.
I've heard it said that confusing designs (both schematic and code) are likely a reflection of the designer's own confusion - not true in all cases, but ceratainly in some. My own take is that messy schematics and code are, basically, selfish - the designer doesn't care if they're clear to anyone else. And this can lead to real costs down the line. Taking the time to create a tidy schematic within the confines of page size, symbol size, and schedule will pay off in the long run, and reflect well on the designer.
The diamond looks the part if the package contains a bridge with four diodes. If the bridge is made from two SOT-23 packages each with a pair of diodes, then the Manhattan placement looks like the parts.
I'd run the nets connected to the LT4321 pins IN36 and IN78 around the outside of the bridges and connect them to the right-most points of the bridges. That leaves the inside of the bridges empty.
Alternatively, I'd consider rotatating the bridge transistors so they're in line and the gate connections are straight. I think this ends up with a visually simpler diagram, though you do lose the obviousness of the bridge.
I leave out the connection dots if they're inside a component symbol, and include them to join net wires that are outside component symbols. So if the bridge is a single 4-pin component, no dots. But if the bridge is composed of discrete diodes, then yes dots.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.