This post takes into account Cargo cult programming. The purpose is to get familiar with the leading definition and consider how does it occur in real life and how to handle it. The term is mostly used as Cargo cult programming however Cargo cult software engineering is more meaningful when it comes to software development. The term provides negative approaches to software engineering. It says what is bad. Correct implementations should avoid practices given in the definition.
Cargo cult software engineering is independent of programming languages and it is focused on approach to design and implementation.
Wikipedia provides the following definition :
“Cargo cult programming is a style of computer programming characterized by the ritual inclusion of code or program structures that serve no real purpose. Cargo cult programming is typically symptomatic of a programmer not understanding either a bug they were attempting to solve or the apparent solution […]. The term cargo cult programmer may apply when an unskilled or novice computer programmer […] copies some program code from one place and pastes it into another place, with little or no understanding of how the code works, or whether it is required in its new position. […]”.
Please refer to the whole Wikipedia definition  in order to get more details.
Cargo cult programming symptoms:
1) Misunderstanding of code which is a subject of change (bug fixing, cleaning up, refactoring)
2) Misunderstanding of self introduced code
3) Introducing code with no real purpose
5) Unnecessary comments
Not only programming
Cargo cult does not occur only in programming. It is a versatile term. It could be addressed to engineering, science  and in fact any other field. It takes place when something is practiced in a way which is not appropriate for a certain area or the deviation from the norm is too high. The origin of the term comes from aboriginal religions that grew up in the South Pacific after World War II , . They had a cult of cargo.
Most symptoms of cargo cult are common however an understanding of the term and setting limits may vary from project to project. In particular it may depend on kind of project and project’s phase. For PoC projects  some symptoms could be allowed e.g. code duplication. It is crucial to distinguish between intended and unwitting symptoms. For example copy&paste in prototypes can be allowed as long as we are aware of it.
For each project can be defined a set of rules which creates development standards. A case of not following these standards might be then considered as cargo cult.
Cargo cult treatment
When cargo cult symptoms have been found then should be taken repair activities. The better approach is to define and perform preventing activities. It is introducing a programmer into a context of a project. Additionally it is showing and explaining referential examples which could be followed. Explaining is a very important part. Proper understanding is a foundation to correct implementation.